Recommandations de sécurisation

Transcription

1 P R E M I E R M I N I S T R E Secrétariat général de la défense nationale Issy les Moulineaux, le n /SGDN/DCSSI/SDO/BAS Direction centrale de la sécurité des systèmes d information Recommandations de sécurisation serveur Web

2 Informations Nombre de pages du document : 47 Evolution du document : Version Rédaction Validation DCSSI Date 0.1 C. Mercier - N. Moreau Philippe Brandt 18 septembre 2002 N /SGDN/DCSSI/SDO/BAS Page 2 sur 47

3 Table des matières 1 Introduction Objectifs des recommandations À qui sont destinées ces recommandations Structure de ce document Présentation des recommandations Avertissements 8 3 Pré-requis Connaissances nécessaires Définition des rôles et tâches Principaux risques du serveur Web Modification de contenu Arrêt ou dysfonctionnement du service Web Révélation d information Servir de base d attaque Politique générale de la sécurité des systèmes d information 11 6 Principes fondamentaux de la SSI Développer et implémenter une défense en profondeur La sécurité des locaux et la sûreté de fonctionnement Ce qu il faut prendre en compte prioritairement sur les lots techniques La défense au niveau du réseau Utilisation de commutateurs Mise en place d outils de détection d intrusion La défense au niveau des hôtes La défense au niveau des applications La défense au niveau des données Principe du moindre privilège Sécuriser : mesures générales Relevé de configuration Préalables de l installation Vérification du système sous-jacent Version du serveur Web à installer Vérification des sources d installation Média physique Installation d un applicatif téléchargé Installation directe depuis un réseau externe Installation Emploi de mots de passe complexes Administration du système Administration locale Administration distante Terminal Services N /SGDN/DCSSI/SDO/BAS Page 3 sur 47

4 SNMP Télémaintenance Sécuriser : mesures spécifiques Sécuriser les systèmes d exploitation Installation du système d exploitation Configuration du système d exploitation Anti-virus Sécuriser l environnement réseau Adapter et contrôler la configuration du pare-feu Sécuriser le serveur Web Mesures génériques de sécurisation d un serveur Web Gestion des utilisateurs Procédures de validation des modifications ou mises à jour Procédures de mise à jour du contenu du site Restrictions de droits Organisation adéquate du contenu Activation du chiffrement SSL Banalisation du serveur Limitation des fonctionnalités du site au stricte nécessaire Sécurisation de l administration à distance Sécuriser le serveur IIS Limiter l installation au minimum de services Méthode d authentification Positionner les droits sur les répertoires virtuels du serveur Définir les droits sur les fichiers journaux Activer et configurer les journaux du serveur Web Restriction d accès par adresses IP ou nom DNS Supprimer les tiers de confiance de la configuration Internet Les pages d enregistrement de Certificate Server Le service d indexation Supprimer toutes les documentations, pages et applications d exemples Supprimer tous les liaisons inutiles Supprimer le support RDS Contrôle du contenu des champs de formulaire Désactiver l affichage de contenu de répertoire Editer toutes les pages d erreurs Invalider l utilisation du répertoire parent Désactiver l appel au shell de commande avec #exec Désactiver l adresse IP dans l entête (Content-Location) Mettre en place un filtrage des requêtes, sécurisation globale d IIS Sécuriser le serveur Apache Les utilisateurs Les fichiers Modification des droits par les rédacteurs : le fichier.htaccess Démarrer le service Suppression des traces permettant d identifier le serveur Apache Les modules Les CGI Les liens symboliques Maintenir le niveau de sécurité : mesures générales Règles d exploitation N /SGDN/DCSSI/SDO/BAS Page 4 sur 47

5 9.1.1 Gestion des correctifs de sécurité (serveurs et clients) Réalisation de fiches réflexes pour gérer les alertes Formation Gestion des comptes et des mots de passe Serveur de secours et de test Gestion des sauvegardes Gestion des éléments temporaires Mise à jour de la PSSI Audits de sécurité Maintenir le niveau de sécurité : mesures spécifiques Exploitation des journaux Réaliser une veille technologique sur les éléments du réseau Autres paragraphes Glossaire 46 Index 47 N /SGDN/DCSSI/SDO/BAS Page 5 sur 47

6 Table des figures 1 analyse de /etc/passwd analyse de /etc/group résultat de la commande PS (serveur Web démarrer) analyse de /etc/shadow Droits sur le fichier httpd.conf et le répertoire apache Configuration dans httpd.conf du nom du fichier de redéfinition des droits Choix du répertoire contenant les données du serveur Web Droits sur les fichiers et repertoires du serveur Web Choix du répertoire contenant les CGI Droits d accès aux CGI Balise de journalisation Droits d accès aux journaux Protection des fichiers en.ht définition du type de serveur Message d erreur par défaut d un serveur Apache Modification des traces Traces obtenues par telnet Exemple d index créé automatiquement par Apache résultat de la requête http :// /server-status Exemple d accès à un répertoire partagé Exemple de configuration de CGI N /SGDN/DCSSI/SDO/BAS Page 6 sur 47

7 1 Introduction 1.1 Objectifs des recommandations Ce guide a pour vocation d aider à sécuriser le serveur Web à l aide de recommandations basées sur l état de l art. 1.2 À qui sont destinées ces recommandations Ces recommandations sont destinées principalement aux administrateurs, responsables de la sécurité des systèmes d information et en général à toute personne ou organisation voulant sécuriser ou vérifier la sécurisation du serveur Web. En particulier ce guide n est pas un guide d administration du serveur Web. 1.3 Structure de ce document Ce document est scindé en plusieurs parties : Partie 1 : introduction générale aux recommandations ; Partie 2 : mise en garde sur l application de ces recommandations ; Partie?? : relevé non exhaustif des principales vulnérabilités liées au serveur Web ; Partie 5 : rappel non technique sur l organisation de la sécurité d un système d information ; Partie 6 : rappel des principes fondamentaux de la sécurité d un système d information ; Partie 7 : recommandations générales sur la sécurisation d un système d information et de serveurs ; Partie?? : recommandations spécifiques à la sécurisation du serveur Web à ne mettre en oeuvre qu une fois, à l installation du système ou lors de la première mise en application de ce document ; Partie 9 : recommandations générales sur les opérations à mener pour conserver un bon niveau de sécurisation dans le temps ; Partie?? : recommandations sur les opérations spécifiques au serveur Web destinées à conserver un bon niveau de sécurisation dans le temps ; Partie?? : éléments techniques complémentaires, comme des listes de contrôle. 1.4 Présentation des recommandations Les recommandations de sécurisation sont scindées en deux phases : Sécuriser (Partie 7 et Partie??) : recommandations à mettre en œuvre une seule fois, à l installation du système ou lors de la première mise en application de ce document ; Maintenir la sécurité (Partie 9 et Partie??) : recommandations à suivre tout au long de la vie du serveur Web pour s assurer que le niveau de sécurité reste constant dans le temps. De plus, chacune de ces phases contient deux parties, dédiées aux mesures générales et aux mesures spécifiques participant à l objectif final. N /SGDN/DCSSI/SDO/BAS Page 7 sur 47

8 2 Avertissements La responsabilité du choix et de la mise en oeuvre des recommandations proposées dans ce document incombe au lecteur de ce guide. Il pourra s appuyer sur la politique de sécurité du système d information et sur les résultats d une analyse des risques de la sécurité des systèmes d information pour déterminer les recommandations les plus pertinentes. Le lecteur devra également réaliser des tests exhaustifs afin de vérifier l adéquation de ces recommandations avec son contexte particulier. Vu la nature évolutive des systèmes d information et des menaces portant sur ceux-ci, ce document présente un savoir-faire à un instant donné et a pour ambition d être régulièrement amélioré et complété. Vos commentaires sont les bienvenus. Vous pouvez les adresser à l adresse postale suivante : Bureau Audits en SSI SGDN/DCSSI/SDO/BAS 51, boulevard de la Tour-Maubourg Paris 07 SP N /SGDN/DCSSI/SDO/BAS Page 8 sur 47

9 3 Pré-requis Ce guide s attache, de manière générique, à la sécurisation d un serveur Web indépendamment du système ou type de serveur choisi. Cependant des informations détaillées seront données pour un serveur Apache sous Linux, ainsi que pour Internet Information Server 4.0 ou 5.0 (NT4 ou Windows 2000). 3.1 Connaissances nécessaires Une bonne connaissance du système d exploitation, du serveur Web et de leurs modes de configuration sont nécessaires pour l application des recommandations détaillées. Une connaissance du protocole HTTP 1 est un plus. 3.2 Définition des rôles et tâches Pour l ensemble de ce document nous considérerons une organisation qui semble adaptée à la gestion d un projet de serveur Web. Les différents postes devraient être les suivants : Administrateur système : Le terme «administrateur système» désigne le responsable système chargé de la configuration et administration de la machine et du système d exploitation sur lequel le serveur Web est installé. Ce guide lui est destiné pour tout ce qui concerne la configuration du système hôte ainsi que la définition des droits des utilisateurs sur le système et les répertoires. L administrateur système veille à la qualité de service et à la mise à jour du système. C est par exemple lui qui contrôlera les journaux système ; Administrateur Web (Webmaster) : Il est responsable de la configuration du service Web. Il travaille le plus souvent en collaboration avec l administrateur système. L administrateur Web a la charge de définir et configurer les services Web, compilateurs et autres modules nécessaires sur la plate-forme. Après 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 complémentaires liés au site. C est par exemple lui qui contrôlera les journaux du service Web, éditera les statistiques de consultation etc. ; Éditeurs : Le terme éditeur regroupe l ensemble des personnes qui participent à la conception du site (programmeurs, développeurs, auteurs, graphistes etc.). Ces personnes ne devraient normalement disposer d aucun accès sur le serveur final et travaillent sur un serveur de test. Une fois le contenu du site validé, l administrateur Web sera chargé de publier les modifications sur le site d exploitation ; Visiteur : Les visiteurs sont les utilisateurs du site Web. Ils naviguent sur le site de manière anonyme le plus souvent. Ce guide intéresse principalement les administrateurs système et administrateurs Web. 1 Hyper Text Transfer Protocol RFC 2068 N /SGDN/DCSSI/SDO/BAS Page 9 sur 47

10 4 Principaux risques du serveur Web Ce chapitre présente les principaux risques et leurs conséquences. 4.1 Modification de contenu Un serveur mal sécurisé peut permettre la suppression, l ajout ou la modification des données hébergées sur le serveur. Il en résulte une atteinte à l image de marque de l entité, de la désinformation, etc. 4.2 Arrêt ou dysfonctionnement du service Web Une des attaques principales contre le serveur est le déni de service. Saturer le serveur de requêtes, arrêter le service, bloquer les ports etc. sont autant de méthodes empêchant le serveur de remplir ses fonctions. Il en résulte souvent une atteinte à l image de marque et la crédibilité de l entité. Les conséquences sont d autant plus importantes que le serveur propose un service ou des informations consultés régulièrement par un grand nombre de personnes. 4.3 Révélation d information Un serveur Web mal configuré et trop bavard peut révéler des informations sur le système l hébergeant et ainsi faciliter son attaque. L introduction de virus, vers et autres programmes malveillants sur la machine peuvent avoir des conséquences physiques sur la machine (destruction de disques durs, effacement du système,...). 4.4 Servir de base d attaque Une compromission de la machine peut la transformer en plate-forme de rebond pour une autre attaque sur les réseaux interne ou externe. Une plate-forme de rebond offre deux avantages aux agresseurs, rendre la tache des enquêteurs plus difficile si la machine compromise sert à attaquer un autre site sur l Internet, ou, utiliser la machine compromise comme passerelle d attaque vers le resau interne de l entreprise. Un serveur situé en DMZ peut, par exemple, disposer de droits supérieurs sur l intranet par rapport aux machines situées sur l internet. Prendre le contrôle de ce serveur permettra donc à un attaquant potentiel de rebondir et attaquer le réseau interne, voire d utiliser le serveur pour attaquer d autres 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. N /SGDN/DCSSI/SDO/BAS Page 10 sur 47

11 5 Politique générale de la sécurité des systèmes d information Un document, la politique de sécurité d un SI (Système d Information) doit exister au sein de l organisme mettant en œuvre le SI. Parmi les règles relatives à la sécurisation du serveur Web présentes dans la PSSI, on doit retrouver au moins les éléments ci-dessous : la fonctionnalité du composant au sein du SI ; la liste des comptes d administration ainsi que les modalités de gestion de ces comptes dans le temps ; la liste des flux entrants/sortants vers/depuis le composant ; la liste des services lancés au démarrage ; la liste des services audités et leurs fichiers ; le suivi des mises à jour des versions des logiciels utilisés ; une copie des fichiers de configuration de tous les services et des fichiers de démarrage ; les mesures de sécurité physique mises en place ; la liste des correctifs et des modifications réalisées sur le composant ; les opérations d exploitation à mettre en œuvre sur le composant. Les recommandations énoncées dans tout ce document devraient également trouver leur place dans les règles de cette PSSI. Le lecteur pourra se reporter au document édité par la DCSSI «Guide pour l élaboration d une Politique de Sécurité Interne» (disponible sur le site internet de la DCSSI, pour plus d informations sur l établissement d une PSSI. N /SGDN/DCSSI/SDO/BAS Page 11 sur 47

12 6 Principes fondamentaux de la SSI 6.1 Développer et implémenter une défense en profondeur Le principe de la défense en profondeur est de multiplier les protections d une ressource (information, composant, service...), à tous les niveaux où il est possible d agir. Ainsi, un agresseur devra passer outre plusieurs protections, de nature et de portée différentes, avant d accéder à la ressource. Ce principe doit être appliqué à tous les stades de la sécurisation d une ressource qu elle qu en soit sa nature : une donnée, une application, un système, un réseau, voire même le local hébergeant le système d information La sécurité des locaux et la sûreté de fonctionnement Ce document n a pas pour objectif de détailler les mesures de sécurité physique à mettre en œuvre pour l exploitation de systèmes d informations sensibles, les principaux points techniques nécessaires seront ici abordés sous l angle de leur sécurisation, sans entrer dans le détail technique de leur mise en œuvre. En particulier, les différents lots techniques, au sens bâtimentaire (incendie, climatisation,...) possèdent un grand nombre de contraintes techniques, réglementaires, légales ainsi que des interrelations qui ne seront pas détaillées dans ce document. Les règles essentielles de sécurité physique à prendre en compte dans la conception ou l aménagement de locaux, en vue de l installation de systèmes d information plus ou moins complexes et sensibles, recouvrent plusieurs éléments de nature différente mais interdépendants. Ces règles à appliquer sur tout ou partie de ces éléments doivent s inscrire en amont de toute autres actions, dont l objectif est de garantir en première instance, l accès physique, l intégrité et la disponibilité d un système d information et de ses données. Les situations géographiques, les implantations et les natures des constructions et des équipements d un site sont importantes au regard des risques naturels, de l environnement et des techniques mises en œuvre. On s attachera donc à examiner les points suivants : L environnement : La typologie des sols, magnétisme naturel, nappes phréatiques, résistance aux effondrements,... ; Les zones inondables, l indice kéraunique du lieu (impacts de foudre), les précipitations, vents dominants (par rapport au voisinage pour les prises d aération),... ; L existence de voies d accès au site et leur praticabilité ainsi que les dessertes V.R.D. (Viabilisation des Réseaux de Distribution) ; La nature de l implantation (zones urbaines, industrielles,...), la prise en compte du POS (Plan d Occupation des Sols) pour l emprise et les extensions bâtimentaires futures, la nature du voisinage (présence, d industries chimiques pouvant induire des pollutions importantes, d aéroports (crash), voies autoroutières ou transports suburbains (vibrations)),... ; L emprise et les bâtiments : L emprise avec son plan de masse indiquant la position, le type et la nature des clôtures, les voies internes de circulation, les diverses accessibilités, l espace réservé aux parkings (personnels, visiteurs),... ; Le gros œuvre, le type et la nature des bâtiments et des toitures (résistance aux charges résultantes des précipitations et jets d objets,...), écoulements des eaux usées et pluviales, positionnement des diverses canalisations,... ; Les lots de second œuvre et répartitions des locaux, type et nature des cloisonnements, modularité, répartition relative, issues (vitrages, portes,...),... ; Les lots techniques, généralités (énergie, ventilation, climatisation, détection/extinction incendie,...), implantation (usage dédié), type, nature, redondance (secours), renvois d alarmes sur défaillance. N /SGDN/DCSSI/SDO/BAS Page 12 sur 47

13 Ce qu il faut prendre en compte prioritairement sur les lots techniques Avant tout, les locaux accueillants les lots techniques doivent être dédiés, l accès à ces derniers ou directement aux composants, ne doivent être accessibles que par des personnels qualifiés, internes ou externes (maintenance), en régime restrictif et contrôlés afin d abaisser les risques potentiels (malveillances, fausses manœuvres,...). Les agressions ou défaillances sur des éléments connexes au système d information peuvent concourir à son indisponibilité totale ou partielle. Pour cela, il y a nécessité de vérifier les points suivants : É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 accès, sous contrôle, au fournisseur (tête de câble). De même, la dernière chambre de tirage avant transformation devra se situer sur le site. Dans le cas ou une seconde arrivée serait mise place (secours), il sera nécessaire de négocier avec le fournisseur un tirage de ligne, pour ce qui est hors site, empruntant un chemin physique différent et venant d une sous station différente ; Le TGBT (Tableau Général Basse Tension) élément sensible de la première répartition de l énergie au sein du site, fera l objet d une attention dans sa localisation et son accessibilité. Par ailleurs, les locaux (ex : PABX (autocommutateur téléphonique), conception ancienne d onduleurs,...) renfermant des batteries et dont la composition est à base d acide, doivent être dédiés et isolés physiquement des matériels auxquels il sont raccordés. Ces locaux seront munis d une ventilation mécanique et aménagés électriquement en antidéflagrant. On vérifiera que les terres et masses (bâtiments, vérins supportant les faux planchers, matériels informatiques, PABX,...) sont conformes à la réglementation (ex : terres informatiques < ou = 1 Ohm,...). Dans la même optique, on s assurera que les divers revêtements de sols ou muraux sont anti-statiques. On veillera à ce que les divers ensembles électriques primaires soient munis de parasurtenseurs ou parafoudre afin de limiter les risques kérauniques sur les matériels pouvant se révéler sensibles aux variations induites sur les différents réseaux (PABX, serveurs,...) Secours énergie électrique Selon l importance du site (au regard de son infrastructure et de ses installations), un secours par groupe électrogène dédié ou partagé peut être envisagé. Sa localisation est des plus importantes. En effet, on peut être confronté à des problèmes relatifs aux vibrations, ainsi qu aux coups de bélier dûs aux ondes stationnaires (longueurs des tubes d échappements des gaz) si ce dernier se trouve en sous-sol ou rez-de-chaussée. Par ailleurs, il faudra s assurer de la présence d un bac de rétention de capacité supérieure à celle de la cuve à fuel de démarrage avec une évacuation conforme à l antipollution. L ensemble des matériels formant le système d information (serveurs, terminaux, imprimantes,...) doivent être raccordés sur un circuit ondulé (régulation) avec une disponibilité d un minimum de 1/4 d heure afin de permettre une extinction propre des systèmes. À ce sujet, l implantation de l onduleur (intermédiaire tampon, en cas de rupture d énergie, entre le fournisseur d énergie et le démarrage du groupe électrogène) ainsi que ses caractéristiques intrinsèques, seront étudiés de manière à ce que toute extension de matériels réclamant une énergie ondulée soit possible. Il est à noter que pour ce qui concerne les PABX, le maintien des batteries en tampon doit être au minimum de l ordre de 48 heures Climatisations et ventilations Les climatisations, quelles soient autonomes ou centralisées, associées aux ventilations sont des éléments dont l importance est vitale pour la vie des matériels (serveurs, PABX,..) par nature N /SGDN/DCSSI/SDO/BAS Page 13 sur 47

14 fortement exothermiques. En effet, elles permettent de les réguler en température et hygrométrie évitant ainsi les surchauffes et diminuant par voie de conséquence le risque incendie. On prendra soin pour les climatisations de relever le type, la nature, et la puissance de dissipation frigorifique. L existence d une redondance, afin d assurer une forte disponibilité, est fortement conseillée. Pour produire du froid, l élément réfrigérant doit être compressé à partir de compresseurs euxmêmes devant être refroidis. Pour cela, des échangeurs thermiques (aérothermes) protégés en malveillance (blocage volontaire des pales de ventilation) devront être installés et disposés de manière à ce qu ils ne causent aucune nuisance sonore (vitesse des pales provocants des sifflements) ni vibratoire. Les VMC (Ventilation Mécanique Centralisé) seront judicieusement positionnées en particulier les prises d aération (au regard des pollutions de l environnement et des vents dominants). Les différentes conductions de ventilation (gaines, faux planchers/plafonds..) et les reprises d air doivent être vérifiées au moins une fois l an et les filtres changés selon l environnement deux à quatre fois par an. L ensemble climatisation/ventilation se doit d être asservi en arrêt sur une détection confirmée d incendie, afin de ne pas devenir un vecteur de propagation Incendie Indépendamment des obligations légales (IGH, (Immeubles de Grande Hauteur)...), il est nécessaire que les locaux accueillants les matériels du système d information ou y contribuant (onduleurs, cellules climatisation, énergie,...) soient protégés contre l incendie. À cet égard, on choisira la nature (flammes, températures, fumées,...) et le type de la détection (statique, différentiel, vélocimétrique,...) afin de l approprier au risque le plus probable (une solution mixte peut être envisagée). Des solutions, manuelles (extincteurs appropriés) ou automatiques (gaz non halogénés, eau pulvérisée,...), d extinction sont à mettre en œuvre pour compléter et agir rapidement sur l extinction d un incendie. Les locaux ainsi que les gaines de ventilation, faux planchers/plafonds devront périodiquement faire l objet d un dépoussiérage afin d éviter ce vecteur complémentaire d incendie. Des alarmes sonores et lumineuses locales avec renvoi vers un poste de surveillance devront accompagner l activation de ces détections. On relèvera la présence des d éléments combustibles (revêtement des parois,,...), lieux de stockage (papier,...), disposition relative des locaux, afin d agir sur ces éléments pour abaisser le risque d incendie. Enfin, il est indispensable d avoir à disposition des procédures et des consignes relatives à l incendie tant en prévention qu en action Dégâts des eaux Les locaux revêtant un caractère sensible au regard du système d information ou contribuant à sa disponibilité doivent être protégés contre le dégât des eaux (inondations, rupture de canalisation,...). Si en terme de confidentialité le positionnement en sous-sols semble remporter la faveur, il est indispensable que ces locaux soient dotés de faux planchers munis de détecteurs d humidité couplés à des pompes de relevage et rendus étanches au regard des étages supérieurs, ou s inscrire dans des unités totalement cuvelées Contrôles des accès anti-intrusion Dans le cadre général, un premier niveau de contrôle d accès (niveau de l enceinte du site), ainsi qu un second niveau (accès aux bâtiments), doivent être installés séparément ou confondus selon la nature du site, leur nature (contrôle humain, électronique, mixte...) et leur type (contrôle visuel, portiques, badges, cartes électronique...). Pour les locaux sensibles (serveurs, PABX,...), un contrôle d accès dans un régime restrictif quel qu en soit le type et la nature sera indépendant ou intégré aux autres contrôles d accès. N /SGDN/DCSSI/SDO/BAS Page 14 sur 47

15 Des systèmes anti-intrusion, actifs ou passifs, à différents niveaux (enceinte, bâtiments, locaux sensibles...) doivent être mis en œuvre. Leur type et leur nature (grillage, barreaux, radars, infrarouge...) doivent être choisis d une manière cohérente au regard de l environnement. Les alarmes, des contrôles d accès et des dispositifs anti-intrusion, ainsi que leurs renvois intégrés ou non dans une unité de gestion centralisée, doivent impérativement être complémentés par des consignes et des procédures. Ces mesures organisationnelles doivent être cohérentes entre elles ainsi qu au regard de leur environnement. Une redondance minimum et une autonomie sont indispensables afin de permettre une continuité a tous les niveaux des contrôles d accès et des dispositifs anti-intrusion. AVERTISSEMENT Les alarmes techniques et celles concernant les contrôles d accès/anti-intrusion sont de natures différentes. On s attachera à ce quelles ne soient pas gérées par les mêmes personnes et quelles ne soient pas techniquement regroupées La défense au niveau du réseau Il faut comprendre ici la défense des flux circulant sur le réseau (limiter les flux autorisés, les chiffrer (contre l écoute et le piratage de session), limiter l utilisation de logiciels d écoute 2...), ainsi que des flux entrants ou sortants du périmètre du réseau (mettre en place des moyens de filtrage, limiter les flux autorisés, limiter les connexions non contrôlées comme les modems) Utilisation de commutateurs La mise en place d un environnement réseau sécurisé passe par la mise en œuvre de commutateurs bien administrés. En effet si l on se passe de commutateurs 3 et que l on utilise des concentrateurs 4, tout le trafic est «diffusé» sur la totalité du réseau local, sans contrôle possible par l expéditeur ou le destinataire. Ainsi, si quelqu un écoute le trafic local, il peut recevoir des informations qui ne lui sont pas destinées. L utilisation de commutateurs est d autant plus recommandée que la grande majorité des protocoles utilisés par les applications classiques (messagerie électronique, navigation Web, accès à des fichiers distants...) ne sont pas chiffrés. Cependant, il faut noter que la protection apportée par un commutateur n est pas parfaite, car sujette à des attaques au niveau du protocole de résolution d adresse (ARP), et doit être complétée par d autres mesures découlant du principe de défense en profondeur Mise en place d outils de détection d intrusion La défense au niveau des hôtes Elle consiste à durcir le système d exploitation d un composant, ainsi que ses relations avec les autres composants du SI La défense au niveau des applications La sécurisation d une application s appuie sur des mécanismes propres à l application, mais aussi sur la sécurisation du système d exploitation sans lequel elle ne peut exister La défense au niveau des données Les données, stockées comme transmises, sont particulièrement vulnérables (mots de passe, contenu de fichiers, de messages électroniques...). Le chiffrement et/ou des mesures de contrôle d accès discrétionnaires permettent de protéger les données stockées. De même, des données transmises sous forme chiffrée seront moins vulnérables en cas d interception. 2 également appelés «sniffers» 3 également appelés «switchs» 4 également appelés «hubs» N /SGDN/DCSSI/SDO/BAS Page 15 sur 47

16 6.2 Principe du moindre privilège Le principe du moindre privilège est de ne permettre que ce qui est strictement nécessaire à la réalisation de la fonction recherchée. Comme le principe de défense en profondeur, il se décline à tous les niveaux d un SI. Il se traduit, par exemple, par la limitation des droits accordés à un utilisateur à ceux nécessaires pour remplir sa mission (utilisation du système, administration, gestion des sauvegardes...) et à aucun autre. N /SGDN/DCSSI/SDO/BAS Page 16 sur 47

17 7 Sécuriser : mesures générales 7.1 Relevé de configuration Il est recommandé d établir et de tenir à jour un relevé de configuration des serveurs en distinguant les différents types de serveurs et leur localisation dans l architecture globale du système d information. Pour chacun de ces types, un document décrira les choix de configuration réalisés, et la liste des mesures particulières à ces systèmes comme, par exemple : les choix réalisés lors de l installation, en terme de partitions, de paramétrages du BIOS... les procédures liées à l identification/authentification des utilisateurs et des administrateurs ; la liste des applications installées et leur version ; la liste des services installés, leur propriété (démarrage automatique, manuel...), la liste des services désinstallés ; le niveau de mise à jour appliqué, en détaillant les mises à jour principales, comme les «Service Packs» de Windows, les correctifs cumulatifs, postérieurs aux Service Packs, tels que les «Rollup Patches» de Windows et les correctifs individuels, postérieurs aux Rollup Patches, appelés «Hotfixes» dans les environnements Windows ; les règles de contrôle d accès aux ressources, et les droits positionnés sur les clés de registre, répertoires et fichiers ; les règles d audit et de journalisation ; les mesures de chiffrement et d empreintes des fichiers critiques contenus sur les serveurs. Les aspects liés à l organisation doivent également être décrits. Ce document devra en particulier être utilisé pour toute nouvelle installation de serveurs de même type. Un volet exploitation devra préciser les tâches liées à la sécurité devant être assurées. On pourra pour cela s inspirer de la structure du présent document. L objectif de ce document est multiple : assurer une continuité de service en cas d absence de l administrateur chargé de l installation du système ; faciliter la constitution d annexes techniques à la PSSI ; savoir sur quels composants assurer une veille technologique. Ce relevé de configuration papier du serveur contient des informations permettant d accéder aux paramétrages du serveur, d identifier les versions du système, des applications, des services, etc. Il doit donc être identifié comme confidentiel et stocké dans un endroit protégé (local fermé à clé par exemple). D une façon pratique, ce relevé de configuration peut être constitué en consignant les choix réalisés lors de l application des différentes parties de ce document. Ce relevé devra bien évidement faire l objet de mises à jour aussi souvent que nécessaire, comme indiqué au paragraphe page Préalables de l installation Vérification du système sous-jacent Avant toute installation d un logiciel, il convient de vérifier que le système, au sens large (système d exploitation ou applicatif) a été installé dans les mêmes conditions que celles décrites ultérieurement et qu il a fait l objet d une sécurisation en se référant, par exemple, au guide DCSSI ad hoc. Cette partie complète les pré-requis évoqués au début de ce document, partie??. D autre part, le système devrait être installé à partir d une nouvelle version, et il ne devrait pas être installé à partir d une mise à jour d une ancienne version. N /SGDN/DCSSI/SDO/BAS Page 17 sur 47

18 7.2.2 Version du serveur Web à installer Il pourrait paraître naturel d installer la version française du serveur Web. Cependant, un des principes de base de la sécurisation est de maintenir le serveur Web au dernier niveau de mise à jour disponible. Sachant que l expérience montre qu il existe un décalage de plusieurs jours, voire plusieurs semaines, entre la publication du correctif dans le langage de l éditeur et leur version francisée, il est recommandé d installer le serveur Web dans sa version originale, très souvent en américain ou en anglais, plutôt que sa version francisée Vérification des sources d installation Lors de l installation d un élément logiciel (système d exploitation ou applicatif) sur une machine, plusieurs méthodes sont disponibles : installation depuis un média physique commercial (disquette, CD-ROM,...) ; installation à partir d une archive préalablement téléchargée sur un réseau externe à l entité ; installation directe au travers d un réseau externe à l entité Média physique Il s agit certainement du mode d installation le plus sûr bien qu un certain nombre de précautions restent nécessaires. Il convient tout d abord de s assurer que le média proposé n est pas une contrefaçon mais qu il émane bien directement de l éditeur. Ensuite, il convient d examiner le contenu de ce média avec un anti-virus et ce quelque soit sa provenance. En effet, il se peut que des personnes indélicates aient introduit des programmes malicieux (virus, chevaux de Troie, etc...) au cours du processus d élaboration du média. Si les fichiers présents sur le média ont fait l objet d une signature numérique par l éditeur, il convient de vérifier la validité de cette signature en utilisant la clé publique de l éditeur et les outils adéquats. Ceci ne constitue cependant pas une preuve irréfutable de l exemption de contenu malicieux qui aurait pu être introduit à l insu de l éditeur avant qu il ne signe le contenu du média. De plus, la signature électronique ne peut qu être un élément de preuve de l identité de l émetteur suivant de nombreux paramètres (dispositif cryptographique employé, mode de récupération de la clé publique, soin apporté par l éditeur dans la gestion de ses clés privées, etc...). Il convient donc de bien comprendre les éventuels mécanismes cryptographiques mis en jeu avant de donner une confiance aveugle à une signature électronique Installation d un applicatif téléchargé La problématique reste la même que pour un support physique. Il convient toujours d effectuer une analyse antivirale avant installation. Le problème supplémentaire posé ici réside dans le mode de récupération des sources qui ne peut être considéré comme sûr. Les mécanismes cryptographiques peuvent permettre de sécuriser ce canal de récupération mais certains problèmes peuvent subsister. On pourra se référer à la note d information n CERTA-2001-INF-004 émise par le CERTA traitant du sujet «Acquisition des correctifs» dont la problématique est proche Installation directe depuis un réseau externe Cette approche est à proscrire absolument car il ne vous est laissé aucune possibilité de personnaliser le processus de vérification des sources avant installation si ce processus existe. Il convient donc de séparer ces deux tâches d autant plus que l installation directe depuis Internet suppose que vous interconnectiez une machine que vous n avez pas encore sécurisé ce qui serait une grave erreur. N /SGDN/DCSSI/SDO/BAS Page 18 sur 47

19 7.3 Installation Dans la mesure du possible, un serveur devrait être dédié à une seule fonction (par exemple, la messagerie). Le principe de moindre privilège (cf. 6.2) doit guider toute installation. Il se traduit par la limitation des fonctionnalités et des services installés au strict minimum requis par la fonction du serveur. Il s agit de limiter les vulnérabilités potentielles qui peuvent apparaître dans les applications, les services, les options système, les couches réseau... Après avoir installé le système, il est nécessaire d appliquer les derniers correctifs fournis par l éditeur. Toutefois la mise en place de tels correctifs nécessite toujours une vérification préalable de leur bon fonctionnement sur le serveur de test afin d éviter d éventuels effets de bords des mises à jour, observés le plus souvent au niveau des applicatifs. L adresse internet suivante permet d accéder aux articles édités par Microsoft sur la parution de nouveaux correctifs : Microsoft met à la disposition du public un outil permettant de contrôler la mise à jour du système : hfnetchk.exe (Hotfix Network Checker). Cet outil exécuté en ligne de commande sur le serveur avec les droits administrateur contrôle l ensemble des mises à jour appliquées au système et aux applicatifs principaux de Windows, comme Internet Explorer, Outlook.... Il nécessite de disposer d une base de signatures à jour. Il est donc recommandé de lancer tout d abord l outil sur une machine connectée à Internet afin qu il télécharge la dernière base de signatures, puis de transférer l outil 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 effectue des tests complémentaires sur le système, comme la vérification du nombre de comptes administrateur présents sur la machine, l existence 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 postérieurs), et Internet Explorer (5.01 et postérieurs). Ces deux outils permettent donc d identifier les mises à jour qui n ont pas été appliquées pour ensuite y remédier. MBSA permet en outre d identifier des vulnérabilités critiques du système d exploitation et des principales applications éditées par Microsoft. Enfin, il est nécessaire de créer une disquette de démarrage Windows, une disquette de réparation d urgence (ERD), et de conserver tous ces médias d installation dans un lieu protégé. 7.4 Emploi de mots de passe complexes Les mots de passe sont souvent la seule et unique protection d un système d information contre l intrusion logique. Une bonne politique de choix et de gestion des mots de passe est donc le passage obligé pour sécuriser une machine, voire un système d information tout entier. Afin d être robuste aux attaques, un mot de passe doit être complexe. Si l environnement dans lequel il est utilisé le permet, un mot de passe complexe doit avoir les propriétés suivantes : il se compose d un nombre suffisant de caractères : au moins sept pour un utilisateur et plus de quatorze pour un administrateur pour les environnements sous Windows, huit caractères pour les systèmes de type Unix/Linux ; il comporte au moins un caractère de chaque catégorie : caractère alphabétique minuscule ; caractère alphabétique majuscule ; chiffre ; caractère spécial (disponible sur le clavier, hors des trois premières catégorie). Pour un sécuriser un compte avec des privilèges étendus sur une application, sur un système ou sur un composant (compte administrateur, communauté SNMP avec droits en écriture...), on peut également envisager l utilisation d un caractère ASCII non imprimable, obtenu en appuyant sur ALT et NB, où NB est un nombre compris entre 1 et 255 pour les environnements Windows. N /SGDN/DCSSI/SDO/BAS Page 19 sur 47

20 il n existe dans aucune langue ni aucun dictionnaire ; il est remis dans une enveloppe cachetée à l officier de sécurité qui la stocke dans un lieu adéquat. L utilisation de tels mots de passe ne saurait être efficace sans une complète acceptation par les utilisateurs et les administrateurs des contraintes associées. En effet, il est primordial de sensibiliser et d informer les utilisateurs aux risques liés à l utilisation hasardeuse des mots de passe : mots de passe triviaux ; mots de passe partagés entre plusieurs utilisateurs ; même mot de passe utilisé pour sécuriser l accès à deux ressources différentes. Cette pratique est particulièrement dangereuse lorsque un même mot de passe est utilisé dans une application qui le transmet en clair sur le réseau (par exemple, la messagerie électronique), où il peut être facilement écouté, et comme authentification d une ressource critique (par exemple, l authentification système). puis de les former à des comportements sécurisés. Ainsi, on peut aider les utilisateurs à choisir un mot de passe complexe, en utilisant par exemple des aides mnémotechniques, expliquer la nécessité d un changement régulier des mots de passe, sensibiliser à leur confidentialité (ne pas partager son mot de passe avec d autres utilisateurs, ne pas communiquer son mot de passe sauf à l officier de sécurité, etc...). In fine, les utilisateurs doivent pouvoir choisir des mots de passe mémorisables ou pouvant être regénérés simplement à chaque utilisation. Dans le cas inverse, cette protection sera rendue inefficace par des comportements inadaptés (mots de passe marqués sur un post-it...). Enfin, une recrudesence d utilisateurs ayant bloqué leur compte ou ne se souvenant plus de leur mot de passe doit être perçue positivement, comme la manifestation de l effort qu ils font pour choisir des mots de passe complexes. Il convient également de garder à l esprit les solutions techniques existantes pour se passer des contraintes inhérentes aux mots de passe : utilisation de systèmes d identification et d authentification forte (carte à puce, clé USB, biométrie, etc...), alliés à des dispositifs dits «Single Sign On», c est-à-dire permettant une identification et authentification forte unique pour toute une session (connexion à une machine, accès à des ressources locales ou distantes...). 7.5 Administration du système Administration locale Il est recommandé d administrer un serveur localement, c est à dire à partir de sa console. Pour ces activités, l administrateur utilisera ponctuellement un compte dédié avec les privilèges adéquats. Pour les tâches ne nécessitant pas de tels privilèges, l administrateur prendra soin d utiliser un autre compte, avec des droits restreints Administration distante Néanmoins, si une administration distante du serveur est requise, elle ne devrait pas pouvoir être réalisée depuis n importe quel poste du réseau interne. Il est donc nécessaire de limiter cette fonctionnalité aux seuls postes des administrateurs, en particulier au niveau de leur adresse IP. Toutefois, l utilisation de stations dans un rôle d administration impose que le niveau de sécurisation de la station d administration à distance soit au moins équivalent à celui du serveur (sécurité physique et logique). S il est nécessaire de se connecter à travers le réseau sur le serveur, il est préférable d utiliser des outils d administration chiffrés, fournis avec le système ou tiers en raison des possibilités d écoute Terminal Services Une solution est d utiliser un client Terminal Services pour se connecter à distance sur le serveur à administrer, si celui-ci met en œuvre un système d exploitation de la famille Windows. Il existe de tels clients pour un grand nombre de systèmes d exploitation, même non Windows. Un administrateur peut donc gérer un serveur à distance. Il est recommandé d utiliser les fonctions de chiffrement N /SGDN/DCSSI/SDO/BAS Page 20 sur 47

21 offertes par le composant Terminal Services (chiffrement «élevé»), afin de protéger les données circulant sur le réseau. Si le service Terminal Services Web est utilisé sur le serveur, on prendra soin de modifier la page web par défaut (/TSWeb/default.htm). Attention toutefois, car ce service requiert l installation d un serveur web, ce qui augmente sensiblement la charge d administration et de sécurisation du Terminal Services Web. Le seul moyen d identification et d authentification étant ici la fourniture d un nom d utilisateur et d un mot de passe, il est particulièrement important que celui-ci soit complexe SNMP SNMP est une couche réseau connue pour ses failles intrinsèques. Elle ne devrait pas être activée ou à défaut ne pas être accessible depuis un réseau non sûr. Si SNMP est activée, les noms de communauté utilisés ne doivent pas être triviaux (public, private, nom_d entité, etc...) et répondre aux mêmes contraintes de complexité que les mots de passe (cf. 7.4) Télémaintenance Si elle existe, la liaison de télémaintenance du serveur ne devrait pas être activée en permanence. Le modem donnant accès à cette fonctionnalité devrait être débranché en fonctionnement normal. Il ne devrait être rebranché que lorsqu une télémaintenance est nécessaire, et après que la demande en ait été faite par un intervenant identifié. Plusieurs mécanismes de sécurisation du modem peuvent être mis en place : modem acceptant des méthodes d authentifications fortes ; modem assurant un rappel automatique d un numéro pré-défini (call-back) ; modem acceptant le chiffrement. Il est recommandé d utiliser ces trois mécanismes conjointement. Si tout ou partie de la télémaintenance est réalisée par des prestataires externes, il convient d imposer des règles très strictes de gestion des moyens d identification/authentification, et de contrôle du personnel en charge de la prestation. En particulier, les mots de passe ne devraient pas être triviaux, ni partagés entre les différents intervenants du prestataire et changés régulièrement, même si cela peut être lourd à gérer par le prestataire. N /SGDN/DCSSI/SDO/BAS Page 21 sur 47

22 8 Sécuriser : mesures spécifiques 8.1 Sécuriser les systèmes d exploitation Les informations décrites dans ce chapitre sont absolument nécessaires à une bonne sécurisation du serveur mais elles ne suffisent pas à configurer correctement le système d exploitation. Il est impératif de se reporter aux recommandations de sécurisation du système concerné, réalisé par la DCSSI Installation du système d exploitation installer le serveur du serveur Web sur une machine dédiée ; n installer que les services requis sur le serveur ; utiliser un disque physique dédié ou au moins une partition différente pour le contenu du ou des sites Web ; supprimer toute la documentation fournie sur le serveur ; appliquer les stratégies de sécurité appropriées Configuration du système d exploitation On veillera également à limiter l accès du serveur Web à un certain nombre de fichiers. bien gérer les droits et permissions des utilisateurs (Si l on est sous un système de type Unix, on installera le serveur dans une arborescence confinée 5.) ; placer les répertoires qui contiendront les fichiers journaux dans un espace de taille suffisante Anti-virus On veillera à ce qu un anti-virus soit installé sur le serveur, configuré de manière à analyser régulièrement les fichiers sur le serveur. Cet anti-virus devra avoir une base de signatures actualisée le plus souvent possible (une fois par jour minimum). De plus, s il est prévu de mettre en place sur le serveur des fonctions d envoi ou depôt de fichiers (au travers de formulaires ou de ftp etc.) veillez bien à inclure une procédure de contrôle antiviral lors de l envoi ou le depôt. 8.2 Sécuriser l environnement réseau Lorsqu on possède une interconnexion avec l extérieur(internet ou intranet), il est nécessaire de mettre en place une architecture sécurisée afin de ne pas laisser de portes d entrée à un attaquant potentiel. Le serveur devrait être positionné au niveau d une zone démilitarisée (DMZ). D autre part, le serveur devrait être redondé par une machine de backup (en plus du serveur de test) pour empêcher une interruption de service, intentionnelle ou accidentelle, et permettre la maintenance. La amchine de backup devra avoir les mêmes caractéristiques que le serveur principal (configuration et mises a jours). On veillera également à sécuriser les éléments annexes du réseau nécessaires à un bon fonctionnement du serveur Adapter et contrôler la configuration du pare-feu Il faudra bien évidemment veiller à configurer les pare-feu en prenant garde à n autoriser que les flux nécessaires et bien identifiés. On fera pour cela un tableau des flux passant à travers les pare-feu et on configurera les pare-feu en fonction de ces flux. HTTP (TCP port 80), HTTPS(TCP port 443) mais aussi les différents flux utilisés par les applications identifiés comme nécessaire et installées. 5 également appelé «chroot» N /SGDN/DCSSI/SDO/BAS Page 22 sur 47

23 8.3 Sécuriser le serveur Web Mesures génériques de sécurisation d un serveur Web Cette partie regroupe l ensemble des procédures que l on cherchera à appliquer sur tout serveur Web afin de le sécuriser. Les parties suivantes détailleront leur application sur les serveurs IIS et apache ainsi que les mesures spécifiques propres à ces serveurs Gestion des utilisateurs La gestion des utilisateurs comprend la manière dont les utilisateurs sont perçus par le serveur, les méthodes d identification etc. Il est préférable de ne pas gérer les utilisateurs du serveur Web en les associant à des comptes au niveau du système d exploitation. En effet, cela ne fait que compliquer la tâche de l administrateur système qui devrait modifier régulièrement les comptes utilisateur, leurs permissions etc. De plus créer des comptes utilisateur sur le système peut être la source de nouvelles failles de sécurité qui permettraient à l utilisateur de se connecter au système directement puis utiliser des failles lui permettant d augmenter ses droits et attaquer le système. Dans le cas où une identification de l utilisateur est nécessaire sur le serveur Web (en raison de services ou fonctionnalités réservés ou personnalisés) plusieurs solutions sont envisageables : besoin minime de confidentialité mais personnalisation du service (forums de discussion, gestion de profils utilisateurs...) : Il sera alors préférable de stocker au niveau du module concerné les différentes informations (login, mots de passe...). Attention : la gestion et le stockage d informations nominatives exigent une déclaration de la base ou du fichier auprès de la CNIL. Il sera préférable de veiller au chiffrement du mot de passe sur la base de données ; besoin moyen / fort de confidentialité, avec ou sans personnalisation de service : mettre en place un certificat sur le serveur Web afin d activer le chiffrement SSL ; besoin moyen / fort de confidentialité ET besoin d identification fort du client : Mettre en place un certificat sur le serveur Web et exiger l utilisation de certificats personnels par le client. Bien entendu il faudra aussi contrôler les certificats utilisateurs, définir ceux accepter, les procédures de mise à jour etc. Cette solution est la plus lourde mais aussi la plus sûre en cas de besoin fort de confidentialité et identification. Cela implique la mise en place d une solution d IGC 6 (PKI 7 ) ; Procédures de validation des modifications ou mises à jour Toute modification du serveur doit d abord être faite sur un serveur de test dont la configuration est en tout point identique au serveur de production. Ceci s applique aussi bien aux correctifs systèmes que logiciels ou aux mises à jour de contenu, ajout de modules etc. Il convient généralement d appliquer la mise à jour au serveur de test et de le laisser fonctionner au moins 24 heures pour contrôler le bon déroulement de l ensemble des tâches journalières (sauvegarde, transfert de journaux etc.). La seule exception à cette règle concerne la mise à jour des signatures de l antivirus qui, elle, doit se faire le plus rapidement possible Procédures de mise à jour du contenu du site Après validation de la nouvelle version du site, ou des ajouts / modifications, l administrateur Web (et lui seul) pourra transférer les nouvelles informations, installer les nouveaux composants etc. Un cahier de maintenance du site devra répertorier de manière précise les opérations faites sur le serveur (système et applicatif). Il permettra d avoir une trace écrite de l évolution du serveur. Il est judicieux de faire une sauvegarde de l ensemble de la machine d exploitation avant l application de toute mise à jour importante. 6 Infrastructure de Gestion de Clés 7 Public Key Infrastructure N /SGDN/DCSSI/SDO/BAS Page 23 sur 47

24 Cette mise à jour est à faire de préférence en période creuse de consultation (se référer aux statistiques de consultation si nécessaire pour déterminer la période la plus propice, n occasionnant qu un minimum de gêne pour l utilisateur). L arrêt du service Web étant peu accepté par l usager, prévoir une redirection momentanée sur une page indiquant que pour raison de maintenance le site est temporairement indisponible. Indiquer une heure de reprise est un plus très apprécié par l utilisateur. Ceci peut necessiter la mise en place momentanée d une machine si le service doit être intégralement arrêté ou interrompu. Pour ce qui est du procédé utilisé pour la mise à jour du contenu, la copie des fichiers sur disquette ou CD puis leur mise en place sur le serveur est préférable à des solutions de mise à jour à distance. Dans le cas contraire, la communication devra être sécurisée avec précaution (voir administration distante) Restrictions de droits Le visiteur du site devra être identifié par le système comme un compte utilisateur dont les droits de consultation ne devront en aucun cas s étendre à l extérieur des répertoires de données du site. Il peut être nécessaire d étendre ces droits à l écriture et/ou l exécution, pour par exemple permettre à l utilisateur de déposer des fichiers sur le serveur ou exécuter des scripts. Attention à ne jamais généraliser cette extension de droits à l ensemble du site. D où l intérêt d une organisation propre du contenu (voir organisation adéquate du contenu ci-après) afin de limiter les droits au strict nécessaire. Rien ne justifie qu un compte autre qu administrateur, administrateur Web et utilisateur Web aient un privilège quelconque sur les arborescences et fichiers du site Organisation adéquate du contenu Les développeurs, concepteurs etc. du site devront veiller à ce qui la structure des fichiers du site soit propre et organisée, non seulement de manière à pérenniser la maintenance et la gestion du site, mais aussi et surtout afin de permettre une définition au plus juste des droits. Ils veilleront particulièrement à séparer images, pages statiques, pages dynamiques, scripts etc. On remarque cependant une tendance de plus en plus marquée des sites à être quasi exclusivement dynamiques. On séparera alors difficilement les pages statiques des pages dynamiques et l ensemble de leurs répertoires auront alors un droit d exécution pour le visiteur. Attention à toujours veiller à la restriction des droits sur les zones d envoi de fichiers etc. En aucun cas l utilisateur ne doit disposer de droits d écriture et d exécution en même tant sur un répertoire du serveur Activation du chiffrement SSL 8 L utilisation du SSL permet le chiffrement des informations échangées entre le client et le serveur. L activation du chiffrement SSL est fortement recommandée pour tout besoin de confidentialité de l information échangée. Attention cependant, l opération de chiffrement/déchiffrement de l information peut s avérer gourmande en ressource pour les machines. Actuellement la plupart des sites Web n activent le chiffrement que pour les pages d identification ou lors de la communication de numéro de cartes bancaires etc. Dans le cas ou des informations échangées s avèrent sensibles, l utilisation de solutions de chiffrement telles que les boîtiers de chiffrement peut être préférable au SSL. Le problème qui se pose concerne alors le déploiement de la solution de chiffrement et sa maintenance. 8 Secure Socket Layer N /SGDN/DCSSI/SDO/BAS Page 24 sur 47

25 Un autre inconvénient du SSL (et de tout chiffrement de bout en bout) peut résider dans le fait que nombre d IDS 9 ne contrôlent pas le code contenu dans les flux SSL, laissant ainsi éventuellement passer des attaques au travers du port SSL qui auraient été identifiées en temps normal sur le flux HTTP standard Banalisation du serveur Chaque système, chaque applicatif peut avoir des failles de sécurité. Permettre à un individu de connaître le système, l applicatif et leur version au travers de la simple consultation de votre page d accueil, c est aussi lui indiquer où chercher des failles de sécurité et lui faire gagner un temps très important qu il aurait pu passer à tenter de découvrir ces informations et qui aurait pu le décourager. Il convient donc de rendre le serveur et son système, si possible (administrateur système), le moins bavard possible. La plupart des serveurs Web permettent en effet de modifier leur signature, d autre nécessitent une édition manuelle de fichiers, de fichiers système voire de la base de registre pour les systèmes sous Windows Limitation des fonctionnalités du site au stricte nécessaire Comme il a déjà été dit dans ce document, plus le serveur a de fonctions, plus il a de failles potentielles. Restreindre les fonctionnalités du serveur au strict minimum et n ajouter ces dernières qu au fur et à mesure que le besoin s en fait sentir est de loin la meilleure solution. Veillez à faire l inventaire de tous les menus d administration du serveur et supprimez ou désactivez tout ce qui n est pas indispensable Sécurisation de l administration à distance De manière générale, il est préférable d éviter les solutions d administration / édition / mise à jour à distance. Ces systèmes vous permettent de travailler sur le site à distance mais peuvent aussi être considérés par un éventuel attaquant comme une voie d attaque de votre serveur. Si, pour des raisons organisationnelles ou géographiques, cette solution est nécessaire, il est important de veiller à plusieurs points : au chiffrement de la communication ; à l identification nécessaire, mot de passe fort ; à un système de connexion activé à la demande (non persistance du modem) ; à la journalisation de l activité de la solution distante et son contrôle méticuleux journalier ; au contrôle des tentatives d accès ; Sécuriser le serveur IIS Les serveurs Internet Information Server se rencontrent sous 2 versions principales (4 et 5). Considérant que les systèmes d exploitation sont à jour la sécurisation de serveur Web antérieur à la version 4 ne sera pas décrite dans ce document. Le serveur IIS4 est la version courante pour tout système Windows NT4 depuis le service pack 4, ou tout du moins Option pack 1. Le serveur IIS 5 se rencontre quant à lui sur des systèmes sous Windows 2000 ou Windows XP. Avant d aborder la sécurisation de ces deux versions du serveur Web de Microsoft, il est souhaitable que l administrateur système ai au préalable appliqué les recommandations de sécurisation du système correspondant. 9 Intrusion Détection System : programmes de détection d intrusion qui surveillent les paquets passant sur le réseau afin de détecter d éventuelles attaques en analysant les requêtes etc. N /SGDN/DCSSI/SDO/BAS Page 25 sur 47

26 Limiter l installation au minimum de services Il serait préférable de limiter l installation à un nombre minimum de services et options, limitant par la même occasion le nombre de failles possibles et les possibilités d attaques. Les services inutiles devraient être désactivés, arrêtés, voire désinstallés si le système le permet. Le serveur IIS nécessite l exécution des services suivants pour fonctionner : event log, le journal d évènements License Logging Service Windows NTLM Security support Provider Service d authentification NTLM Service RPC (Remote Procedure Call) Windows NT serveur ou Workstation IIS admin service Service d administration IIS MSDTC World Wide Web publishing service Service de publication WWW Protected Storage Méthode d authentification Par défaut IIS propose 4 solutions d identification : Anonyme : Dans ce cas l utilisateur navigant sur le serveur est identifié par le compte anonyme configuré (propriété du serveur/ identification). Le compte par défaut qui est utilisé et créé lors de l installation du serveur est de la forme IUSR_Nom-du-serveur.Il peut s avérer judicieux de renommer ce compte et d en changer le mot de passe, le mot de passe original étant créé aléatoirement à l installation. Changer le nom du compte évite aussi que l utilisateur connaisse éventuellement le nom de la machine par le nom d utilisateur anonyme. Basique : Dans ce cas, l utilisateur est identifié par un compte et mot de passe existant dans la base utilisateurs du serveur. Des informations transitent sur le réseau en clair, y compris et surtout le compte et le mot de passe utilisés lors de l identification. Identification de type Windows : Dans ce cas l identification se fait au travers du challenge Windows d ouverture de session, le mot de passe ne passe pas en clair, mais nécessite souvent l ouverture de ports supplémentaires pour permettre l identification. De plus, il est souvent nécessaire de spécifier le nom du domaine ou de la machine sur lequel se trouve le compte ce qui complique singulièrement l authentification. Certificats client : Le système d exploitation Windows permet aussi l utilisation de certificats client. Il est possible de refuser, accepter ou exiger des certificats clients. Refus : les certificats client (lorsqu il y en a) sont ignorés ; Acceptation : un utilisateur ayant un certificat client installé sur sa machine (logiciel, carte à puce etc.) se verra demander la clé de son certificat puis pourra l utiliser ; Certificat exigé : l utilisateur ne sera pas accepté sans certificat. Attention cependant, par défaut le serveur ne fait que demander le challenge de certificat, rien n empêche l utilisateur de se faire lui même un certificat logiciel et de l utiliser pour entrer. Dans le cas d utilisation de certificats, l administrateur devra faire l inventaire des certificats qu il acceptera et utiliser l option de liaison des certificats qui lui permet d associer des certificats à des comptes ou groupes d utilisateurs. L authentification de l utilisateur n a d intérêt que dans le cadre de serveurs à contenus interactifs ou participatifs (forums de discussion,...), et de serveur avec un besoin de confidentialité ou de restriction d accès. N /SGDN/DCSSI/SDO/BAS Page 26 sur 47

27 Dès lors qu un besoin de confidentialité se fait sentir, la mise en place d un certificat sur le serveur est un minimum. Il permettra le chiffrement SSL de l ensemble des échanges entre le serveur et le visiteur. La limitation de l accès au serveur peut ensuite se faire au travers de l utilisation d identifiants et mots de passe. S il s agit d un besoin de restriction d accès plus que d authentification forte, l utilisation d identifiants et mots de passe à l intérieur de l application ou d une base de données suffit. Il est préférable d éviter l utilisation d identifiants et mots de passe système, non seulement à cause des risques éventuels de connexion illicite au serveur, mais aussi et surtout pour des raisons d administration de ces identifiants et mots de passe. Dans le cas où il y a un besoin d identification forte (pour des besoins de traçabilité, imputabilité, de signature électronique,...) l utilisation de certificats clients s impose. Attention, il s agit d une structure imposante, complexe à mettre en oeuvre et gérer qu il convient de ne pas prendre à la légère Positionner les droits sur les répertoires virtuels du serveur Comme il a été expliqué précédemment au chapitre , page 24 (Organisation adéquate du contenu), il convient de regrouper les fichiers d un site Web en fonction de leur type afin de positionner de manière plus sûre les droits, il est alors aisé de positionner un droit d exécution à tout le monde sur les répertoires de «scripts» et d «include», et de lecture seule sur les répertoires de contenu statique et d images Définir les droits sur les fichiers journaux les fichiers journaux (log) du serveur IIS (%systemroot%\system32\logfiles ) doivent avoir les ACL 10 suivantes : contrôle total : administrateurs et système ; création, lecture, écriture : tout le monde ; Cette mesure a pour but d éviter qu un éventuel attaquant ne vienne effacer les traces de ses actions sur le serveur Activer et configurer les journaux du serveur Web Afin de pouvoir tracer toute tentative d attaque sur le serveur Web il est nécessaire d activer les journaux de ce dernier. Le format de fichier à utiliser est W3C étendu 11. Activation des logs W3C étendu : A partir de la fenêtre d administration du service WEB, clic droit sur le site Web / Propriétés / Site Web / activer les logs - Mode W3C étendu -, puis activer les options suivantes en cochant les cases correspondantes : Adresse Ip du client ; Nom d utilisateur ; Méthode ; URI stem ; Etat HTTP ; Erreur WIN32 ; User Agent ; Adresse IP serveur ; Port Serveur. 10 Access Control List : table informant le systèmes des droits des utilisateurs (ou groupe d utilisateur) sur un objet particulier du système, tel qu un fichier ou un répertoire. 11 Format ASCII paramétrable disposant de divers champs. Possibilité d inclure les champs qui semblent importants et limiter la taille du fichier en supprimant ceux jugés non nécessaires. Les champs sont séparés par des espaces. L heure est enregistrée en temps UTC(GMT) N /SGDN/DCSSI/SDO/BAS Page 27 sur 47

28 Restriction d accès par adresses IP ou nom DNS Cette option peut s avérer utile dans le cadre d un intranet ou les adresses IP ne sont pas dynamiques ou pour un serveur Internet dont l adresse des clients ne change jamais. Attention cependant, l usurpation d adresse IP permettant de se faire passer pour une autre machine, ce système est loin d être absolument sûr. Cela reste cependant une mesure de sécurité supplémentaire dans le cas où, par exemple, l on dispose dans la DMZ du serveur Web et de la base de donnée sur deux machines distinctes. Relier alors le serveur Web à la base de données par une carte réseau dédiée et n autoriser que l adresse du serveur de base de données sur cette carte dédiée et uniquement l adresse du serveur Web sur la carte du serveur de base de données est déjà une mesure de sécurité supplémentaire. Il conviendra aussi de changer le réseau de cette connexion pour encore plus de sécurité Supprimer les tiers de confiance de la configuration Internet Lors de son installation Internet Explorer installe plusieurs autorités de certification en les définissant de confiance. Dans le cadre où l on utilise le chiffrement SSL, et que l on accepte les certificats il est important de supprimer l ensemble de ces certificats racine. Attention, la majorité des services pack ou correctifs de sécurité mettent à jour ou réinstallent ces certificats racine. Il conviendrait de contrôler la liste des certificats de confiance après chaque mise à jour du système. En fonction de votre navigateur la méthode de suppression de ces autorités de certification diffère. L utilisation de Internet Explorer 5 (ou d une version ultérieure) est fortement recommandée en raison des différentes failles de sécurité d IE 4. IE4 : la suppression des certificats racine n est pas possible, il est nécessaire de les définir comme n étant plus de confiance. Pour ce faire on éditera la base de registre pour définir toutes les entrées inconnues de la ruche HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\SecurityProviders\SCHANNEL\CertificationAuthorities à 0x0. Il est inutile de supprimer les entrées, la DLL SCHANNEL.DLL qui gère ces certificats les recréerait automatiquement. IE5+ : la suppression des autorités de certification se fait directement depuis le navigateur. Outils / Options Internet / Contenu / Certificats / Autorités principales de confiance puis supprimez toutes les autorités non reconnues. Procéder de même avec les autorités intermédiaires. Après avoir changé les autorités de certification l arrêt et le redémarrage du serveur sont nécessaires Les pages d enregistrement de Certificate Server Lors de la configuration de Certificate Server 12, des pages ASP 13 d enregistrement sont installées par défaut. Ces pages ne sont pas sécurisées. Il est conseillé de supprimer ces pages ou d en restreindre l accès au minimum. Ces pages se trouvent dans le répertoire %systemroot%/certsrv. Les ACL devraient être positionnées comme suit : groupe ADMINISTRATEURS (contrôle total) ; groupe Gérants Certificats (contrôle total) ; compte SYSTEME (contrôle total). Note : dans le cas ou l on envisage d utiliser Certificat Server uniquement pour chiffrer la communication, un certificat autosigné par le serveur à l aide de certificate server peut suffire. En revanche dès lors que l on envisage l usage de certificats clients il n est pas recommandé d utiliser la même machine pour la création/gestion des clés et pour le serveur Web ou l applicatif quel qu il soit. En dehors de toute considération de qualité ou services proposés par l application de gestion de clés, il est recommandé de séparer physiquement les deux activités. 12 serveur de création/gestion de certificats de Microsoft 13 Active Server Pages : pages dynamiques en.asp contenant des scripts interprétés coté serveur N /SGDN/DCSSI/SDO/BAS Page 28 sur 47

29 Le service d indexation L utilisation de toute application supplémentaire sur le serveur Web est déconseillée (limitation des services au minimum), l indexation du serveur reste cependant une fonction considérée comme minimum sur un site WEB. Il est préférable d utiliser une machine dédiée à l indexation du ou des serveurs Web. Dans le cas ou l on souhaite utiliser Index Server 14, il est important de prêter attention à plusieurs choses : Aspect sécurité : Mises à jour : Le moteur de recherche étant une application disposant de privilèges, il est recommandé de veiller à ce que toute mise à jour de sécurité concernant Index Server soit appliquée. Certaines attaques en déni de service ou escalade de privilèges peuvent en effet viser les failles du service d indexation. Les répertoires indexés : Si vous utilisez le service d indexation Microsoft il est primordial de bien contrôler les répertoires que vous indexez. Veillez bien à n indexer que les répertoires dont le contenu est public, sans quoi l ensemble de vos scripts, fichiers de paramétrage et commentaires pourraient aussi être indexés. Aspect organisationnel : Taille de l index : Un index occupera en général un peu plus d un tiers du volume des pages indexées. Temps de réponse : Le fait d installer un service d indexation sur le serveur peut entraîner une augmentation du temps de réponse. Pour un site assez important ou à forte consultation, ou encore plusieurs sites, il sera préférable d utiliser un serveur dédié à cette tâche Supprimer toutes les documentations, pages et applications d exemples De nombreux exemples de codes et d applications sont intégrés lors de l installation par défaut du serveur IIS. Il est recommandé de désactiver le serveur par défaut et de recréer un serveur dans un autre emplacement du disque (de préférence dans une autre partition que le système comme indiqué auparavant). Il est cependant souhaitable de supprimer le répertoire des serveurs Web et FTP par défaut en enlevant le répertoire c :\inetpub. Supprimer auparavant le site Web par défaut de la console d administration afin d éviter tout message d erreur. Le répertoire comprend non seulement un site d exemple, mais aussi les fichiers du SDK 15 (c :\inetpub\iissamples\sdk), mais aussi des scripts d administration distante (c :\inetpub\adminscripts). Il est également nécessaire de supprimer les exemples d accès aux données (c :\Program Files\Common Files\System\msadc\ Samples) Supprimer tous les liaisons inutiles Par défaut IIS est configuré pour gérer plusieurs extensions communes dont certaines peuvent s avérer dangereuses. L extension.htr par exemple permet la ré-initialisation de mot de passe. En fonction de ces extensions, le système fait appel à des DLL 16. L exploitation de failles dans ces DLL est alors possible. Il convient donc de limiter la configuration d extensions au strict minimum requis pour l utilisation du site. Par défaut il est recommandé de supprimer la configuration de toute extension inconnue. Gérer les extensions : depuis la console d administration IIS, clic droit sur serveur WEB / Propriétés / Master Properties / WWW service / edit / Répertoire racine. Ci après les extensions installées par défaut à supprimer :.htr : cette extension est utilisée pour la réinitialisations de mot de passe ;.ida : extension d Index Server, à supprimer si vous ne l utilisez pas ; 14 moteur d indexation / recherche des pages du serveur Web intégré de Microsoft 15 Software Développent Kit 16 dynamic Link Library N /SGDN/DCSSI/SDO/BAS Page 29 sur 47

30 .idc : connecteur de base de données internet (Internet Database Connector), à présent les bases de données utilisent des connecteurs ADO 17..shtm,.stm,.shtml : inclusion coté serveur. Tout fichier dont l extension n est pas configurée sera envoyé au visiteur tel quel, comme un téléchargement de fichier Supprimer le support RDS 18 Il est primordial de supprimer le support de service distant. L attaque au travers des DLL MSADC est une des attaques les plus courantes, elle entraîne au minimum le déni de service, au pire la prise de contrôle total de la machine. Pour supprimer les fonctionnalités RDS, supprimez le répertoire /msadc de la racine du site par défaut (au cas où vous n auriez pas encore supprimé ce site) puis supprimez les clés 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ù l utilisation de RDS est nécessaire, l installation de la dernière version de MDAC 19 et sa configuration pour fonctionner en safe mode seront nécessaires. Pour plus d information sur ce point particulier, consulter le site Technet de Microsoft, en particulier le bulletin de sécurité MS99_025 (http :// Il convient aussi de surveiller régulièrement le journal d évènement de votre serveur pour identifier ce type d attaques en recherchant des lignes ressemblant à ceci : :23:12 - POST /msadc/msadcs.dll... vous pouvez aussi faire la recherche plus facilement en cherchant directement "msadcs" dans le/les fichier(s) journaux Contrôle du contenu des champs de formulaire Une attaque courante sur les serveurs ayant des formulaires réside dans l envoi de code malicieux au travers des champs de formulaires, ceci afin de déstabiliser le système, injecter du code dans la base de données ou prendre le contrôle de la machine. Il est donc important de sensibiliser des développeurs du site Web au contrôle des différents champs retournés par l utilisateur au travers des formulaires. Il est primordial de traiter tous les champs retournés par le visiteur avant de les utiliser dans un quelconque procédé. Il sera profitable de mettre en place sur le serveur un module dédié au contrôle des caractères utilisés. Le seul champ pour lequel certains caractères spéciaux peuvent sembler nécessaires est le champ de mot de passe Désactiver l affichage de contenu de répertoire Le site Web dispose de pages par défaut (default.htm, default.html, default.asp,...), ainsi lorsqu un utilisateur appelle un répertoire quelconque du site sans préciser le nom d un fichier à afficher, c est l une de ces pages que le serveur cherchera à afficher. En absence de l une de ces pages, le site affichera une erreur ou le contenu du répertoire. Il est primordial de contrôler que la configuration du site ne montre pas le contenu du répertoire dans un tel cas. Pour ce faire on décochera l option «afficher le contenu du répertoire» dans le menu d administration du site. 17 ActiveX Data Object 18 Remote Data Service 19 Microsoft Data Access Component N /SGDN/DCSSI/SDO/BAS Page 30 sur 47

31 Une deuxième sécurité consiste à positionner dans chaque répertoire une page de redirection à la racine ou encore à éditer la page d erreur correspondante, comme expliqué ci-après Editer toutes les pages d erreurs il est possible d éditer chacune des pages d erreur standard du site web. Il serait préférable que l ensemble des pages d erreur du site soient identiques, ne permettant ainsi pas à l utilisateur de deviner le problème rencontré lors du traitement de sa requète. Cette page d erreur devrait être éditée à la charte graphique du site et proposer un lien vers la page d acceuil du serveur ainsi qu un liens vers une adresse de messagerie de l administrateur du site auquel l utilisateur aurait la possibilité d écrire pour expliquer dans quelles conditions il a rencontré un problème en navigant. De plus, il est recommandé de veiller à ce que les différents scripts ou programme tiers ajoutés au serveur traitent leurs messages d erreur de manière interne, et ne remontent au serveur que des pages banalisées. Les developpeurs devront veiller a utiliser un moyen de traitement de l erreur et non se contenter d un affichage sur la fenêtre de navigation. En effet, saisir des informations erronées ou non conformes afin de provoquer volontairement une erreur lors du deroulement du code est une méthode simple de découvrir en autre le chemin physique des pages de code, le nom de la base de données, le nom de l utilisateur par défaut etc. etc Invalider l utilisation du répertoire parent Par défaut IIS permet à l utilisateur d utiliser «..» à l intérieur de l adresse saisie pour remonter au sein de l arborescence du site. Il est impératif de désactiver cette option pour éviter que le visiteur puisse remonter du site à la racine du disque puis redescendre dans les répertoires systèmes et exécuter des commandes, même si ceci est normalement impossible en raison du positionnement des ACL sur le système. On désactivera cette fonction dans la console d administration du service Internet : clic droit sur la racine du site Web, Propriétés / Répertoire racine / Configuration / option d application et décochez «répertoire racine» Désactiver l appel au shell de commande avec #exec Cette commande pouvant être utilisée pour exécuter un code arbitraire sur le serveur à partir de pages HTML, il est important de contrôler que son utilisation est bien désactivée, sachant qu elle l est par défaut lors de l installation d IIS. Il faudra contrôler que la clé de registre suivante est bien à zéro. \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters \SSIEnableCmdDirective Désactiver l adresse IP dans l entête (Content-Location) Par défaut, lors de l envoi d une page statique (telle que Defaut.htm), l information Content- Location est ajoutée à l entête de la page envoyée. Cette information contient par défaut l adresse IP de la machine et non son nom DNS. Cette information contenue dans l entête permet à un attaquant de connaître l adresse réelle de votre machine dans le cas où la véritable adresse du serveur est masquée derrière un pare-feu ou tout autre système opérant une translation d adresse. Dans ce cas l entête de la page peut ressembler à ceci : HTTP/ OK Server: Microsoft-IIS/4.0 Content-Location: Date: Thu, 18 Feb :03:52 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Wed, 06 Jan :56:06 GMT ETag: "067d136a639be1:15b6" Content-Length: 4325 N /SGDN/DCSSI/SDO/BAS Page 31 sur 47

32 l entête n étant pas modifiée par le pare-feu ou les systèmes de mandataires(proxy), elle expose à l extérieur une partie du plan d adressage interne de l entité. Une valeur doit être corrigée dans la metabase d IIS, pour changer l adresse IP par le nom DNS de machine, ceci grâce à Adsutil.vbs. Pour ce faire, il faudra ouvrir une fenêtre de commande, aller dans le répertoire winnt\system32\ inetsrv\adminsamples puis taper la commande : adsutil set w3svc/usehostname true l entête deviendra ainsi : HTTP/ OK Server: Microsoft-IIS/4.0 or Microsoft-IIS/5.0 Content-Location: Date: Thu, 18 Feb :08:44 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Mon, 30 Nov :40:15 GMT ETag: "f07f84b9771cbe1:3068" Content-Length: Mettre en place un filtrage des requêtes, sécurisation globale d IIS Certains attaquants contournent l interdiction de remonter les répertoires en glissant des caractères spéciaux dans l adresse de leur requête. Le serveur ne reconnaît pas immédiatement ces caractères comme étant des accès aux répertoires parents et laisse passer la requête qui une fois interprétée permet de remonter dans l arborescence, en dehors du site Web afin d atteindre et exécuter des commandes système. Le fait d avoir monté le site Web sur une partition dédiée est déjà un bon moyen de restreindre l attaque. Cependant il est plus qu intéressant de pouvoir bloquer et identifier ce type d attaque. Pour ce faire, Microsoft propose des outils de sécurisation tels que IIS Lockdown Tool (http :// et Urlscan Security Tool (http :// Le premier contrôle plusieurs points de sécurité du serveur et se révèle un outils incontournable de sécurisation globale d IIS. Le second contrôle les requêtes passées au serveur, les dernières versions d IIS Lockdown Tool intègrent à présent Urlscan Sécuriser 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 connaître celles dont vous avez réellement besoin, les risques qu elles incluent et désactiver les autres. Un grand point de la sécurité d un serveur Web : les rédacteurs du site Web représentent un risque. Légalement il est du devoir de l administrateur d éviter que l on puisse utiliser ses serveurs comme base d attaque. Pour ce faire il serait bon de se prémunir contre les failles que pourraient introduire, intentionnellement ou non, toute personne pouvant «intervenir» sur le site Web. Les différents chemins des fichiers donnés en exemple sont valables sur Debian (Gnu/Linux) Les utilisateurs Une configuration par défaut du serveur Apache n utilise, en plus du compte root, qu un seul compte www-data (sur Debian GNU / Linux) aux droits très restreints. Il est utilisé par le serveur Apache pour accéder aux données mises à sa disposition. Cette configuration nécessite que toute modification du serveur ou des données soit faite par un utilisateur disposant des droits administrateur. Il serait préférable d utiliser la configuration suivante, afin de diminuer les conséquences d une erreur humaine et de mieux tracer les modifications apportées par chaque intervenant. Néanmoins l application des autres recommandation reste primordial pour un serveur n utilisant que les comptes par défaut. Trois types de compte, hormis l utilisateur «root», existent sur le serveur Apache (cf. figure 1) : N /SGDN/DCSSI/SDO/BAS Page 32 sur 47

33 le ou les comptes du ou des administrateurs Web. Ils auront accès à la configuration du serveur et devront donc être capables, entre autres, d éditer le fichier httpd.conf (webadmin dans les exemples) ; les comptes des rédacteurs qui n auront accès en écriture qu à l arborescence du serveur Web (/var/www) et en seront les propriétaires. L accès au répertoire des CGIs demande une politique particulière de validation du contenu (par l administrateur Web) webpublisher dans les exemples ; Le compte utilisé, uniquement par le serveur, pour répondre aux demandes de connexion ( User www-data). Attention ce compte doit avoir le droit de lecture et de parcours sur l arborescence des fichiers Web. Les trois comptes appartiennent au groupe «apache» (cf. figure 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 vérifier quel est le compte utilisé par le serveur Apache pour accéder aux fichier à la demande de l utilisateur. On constate que seul le processus père (251) est root. Les demandes des utilisateurs connectés seront traitées avec le compte «www-data»(cf. figure 3). ps -ef grep apache root :22? 00:00:00 /usr/sbin/apache www-data :29? 00:00:00 /usr/sbin/apache Fig. 3 résultat de la commande PS (serveur Web démarrer) Ce compte, aux droits les plus restrictifs possibles, ne devrait, normalement, pas servir. Il ne devrait donc pas être nécessaire que «www-data» dispose d un interpréteur de commande («shell»). Cela se vérifie dans le fichier /etc/passwd (cf. figure 1). Le «/bin/false» en fin de ligne démontre que le compte «www-data» ne dispose d aucun shell. Il serait aussi plus sécuritaire de bloquer ce compte en mettant, par exemple une étoile à la place du mot de passe dans /etc/shadow (cf. figure 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 N /SGDN/DCSSI/SDO/BAS Page 33 sur 47

34 Les fichiers Les exemples sont présentés pour une configuration avec les trois comptes. La vérification des droits d accès des fichiers et répertoires est tout aussi importante si la configuration utilise la configuration des comptes par défaut Les fichiers de configuration Apache n utilise plus qu un seul fichier pour sa configuration : httpd.conf (/etc/apache/httpd.conf ). #ls -al /etc/apache grep httpd.conf -rw webadmin root 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 fichier httpd.conf et le répertoire apache Ce fichier ne doit être accessible en lecture comme en écriture que par root ou l administrateur du site Web. Il devra contenir tous les commentaires nécéssairent à sa bonne comréhension. Le répertoire contenant ce fichier ne doit offrir de droit en écriture qu à root (cf. figure 5). Attention seul root peut démarrer arrêter ou relancer le serveur. Une utilisation, par exemple, de «sudo» (http :// envisageable pour étendre les droits de webadmin et ainsi lui permettre de faire prendre en compte les modifications de httpd.conf sans intervention de root. Certaines variables de configuration peuvent cependant être modifiées par les rédacteurs à l aide du fichier (nommé par défaut).htaccess positionné dans l arborescence du serveur. Dans le fichier httpd.conf on trouve le nom de ce fichier avec la balise AccessFileName. # # AccessFileName: The name of the file to look for in each directory # for access control information. # AccessFileName.htaccess Fig. 6 Configuration dans httpd.conf du nom du fichier de redéfinition des droits L utilisation de ce fichier (cf. figure 6) sera explicitée plus loin dans ce document Les droits d accès système aux fichiers de l arborescence du serveur Les droits de l utilisateur Apache (www-data) devraient être minimum pour limiter les possibilités d attaque en cas de faille sur le serveur. Le défaut est souvent rwxr-xr-x. Pour une bonne sécurité le repositionnement de ces droits devrait absolument être mise en œuvre. Le répertoire contenant les fichiers mis à disposition des visiteurs par le serveur Web est défini dans le fichier httpd.conf par DocumentRoot (cf. figure 7). La racinde du serveur Web ne devrait jamais etre la racine du serveur 20. DocumentRoot /var/www 20 (DocumentRoot /) Fig. 7 Choix du répertoire contenant les données du serveur Web. N /SGDN/DCSSI/SDO/BAS Page 34 sur 47

35 Le positionnement des droits présentés ici concerne le serveur Web (www-data, du groupe apache). Pour les répertoires R : permet de lister le contenu d un répertoire. Ce droit n est utile que pour la création d index automatique et ne devrait donc pas être positionné par défaut ; W : Il permet la création ou la suppression de fichier. Ce droit, dangereux pour la sécurité, ne devrait pas être positionné par défaut ; X : Il permet de traverser un répertoire et est donc nécessaire pour l utilisateur du serveur Web. Pour les fichiers R : Il permet d accéder au contenu et est donc nécessaire pour l utilisateur du serveur Web ; W : Il permet l édition de fichier. Ce droit, dangereux pour la sécurité, ne devrait pas être positionné par défaut ; X : Il permet à un fichier d être exécuter. Ce droit, dangereux pour la sécurité, ne devrait être positionné que pour le ou les fichiers exécutables (CGI) et uniquement dans le répertoires qui leur est explicitement réservés. L appartenance de l arborescence au rédacteur (cf. figure 8) lui permettra de mettre à jour les pages Web sans autre intervention et de garder l autorisation de lister le contenu des répertoires. L accès en lecture seule au groupe «apache» laisse la possibilité au serveur Web («www-data» fait parti de ce groupe) de lire et d en afficher les pages. /var# ls -l grep www drwx--xr-- 4 webpublisher apache 4096 Oct 31 14:41 www /var/www# ls -l total 24 drwx--x--- 2 webpublisher apache 4096 Oct 31 10:58 ficdir -rwxr webpublisher apache 21 Oct 31 10:57 fictest.html -rwxr webpublisher apache 4110 Aug 13 06:31 index.html Fig. 8 Droits sur les fichiers et repertoires du serveur Web Le répertoire des CGI Le répertoire contenant les CGI est défini dans le fichier httpd.conf par ScriptAlias (cf. figure 9). ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ Fig. 9 Choix du répertoire contenant les CGI. Ce répertoire, comme il sera rappelé plus loin dans ce document, est l unique endroit où le serveur Web devrais pouvoir exécuter du code. Pour limiter la possibilité d introduction de faille, volontairement ou non, par les rédacteurs, il est conseillé que seul l administrateur du site Web puisse déposer, lire ou lister les fichiers dans ce répertoire. Il est par contre nécessaire pour le bon fonctionnement du serveur que www-data (le serveur Web) puisse exécuter les programmes qui s y trouvent. Cela se fait en donnant au groupe «apache» les droits en exécution sur le répertoire et les fichiers qui s y trouvent (cf. figure 10). N /SGDN/DCSSI/SDO/BAS Page 35 sur 47

36 # ls -l /usr/lib grep cgi drwx--x--- 2 webadmin apache 4096 Oct 4 15:42 cgi-bin /usr/lib/cgi-bin# ls -l total 60 -rwx--x--- 1 webadmin apache Nov 7 14:03 cgi_de_test Fig. 10 Droits d accès aux CGI. Rappel : Il est très fortement déconseillé de choisir un répertoire pour les CGI dans l arborescence du serveur (/var/www) Les journaux Les balises définissant les fichiers de journalisation ( /var/log/apache/ ) dans httpd.conf sont : CustomLog et ErrorLog (cf. figure11). CustomLog /var/log/apache/access.log combined ErrorLog /var/log/apache/error.log LogLevel warn Fig. 11 Balise de journalisation Warn (cf. figure11) 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 particulière, remplir les journaux et endommager le bon fonctionnement du serveur. Il est conseillé de limiter l accès aux journaux à l administrateur du site Web (cf. figure12). /var/log/apache# ls -l total 24 --wx webadmin apache :05 access.log --wx webadmin apache :33 error.log Fig. 12 Droits d accès aux journaux Rappel : Les journaux contiennent des données sensibles concernant le serveur et les visiteurs (exemple : les «REFERER» 21 ). Ils ne devraient jamais accessible depuis le Web Modification des droits par les rédacteurs : le fichier.htaccess Le serveur Apache permet au rédacteur de redéfinir la configuration, sans redémarrer le serveur, à l aide d un fichier situé dans le répertoire dont le rédacteur veut modifier les possibilités. Ce fichier est fréquemment utilisé pour positionner une limitation d accès par utilisateur. Avec des droits mal positionnés dans le httpd.conf il permettrait par exemple à un rédacteur (ou un pirate parvenant à déposer un fichier) de changer le fichier de mot de passe utilisé par le serveur ou d autoriser l utilisation de lien symbolique vers d autres fichiers du disque. 21 Par défaut les navigateurs envoient, lorsqu un lien est cliqué, non seulemement la demande de la page mais aussi, la totalité de la requête précédente qui peut, par exemple, contenir l identifiant mail d un visiteur en provenance de sa boite aux lettres N /SGDN/DCSSI/SDO/BAS Page 36 sur 47

37 La directive AllowOverride La directive AllowOverride fait partie d Apache. Cette capacité ne peut donc pas être désactivée. Il est important d avoir bien compris la portée des directives selon leur placement par rapport aux différents blocs 22 du fichier de configuration. Elle peut avoir comme valeur : All : Avec cette valeur presque toute la configuration peut être modifiée (suivis des liens symboliques...). Dangereuse pour la sécurité, elle ne devrait pas être utilisée ; None : L utilisation de cette valeur devrait être systématiquement utilisée à la racine du serveur Web. Elle interdis toute modification utilisant.htaccess ; AuthConfig : Cette valeur permet la modification des autorisations. Elle ne devrait être positionnée qu à la demande des rédacteurs, dans les blocs définissant les répertoires ou un contrôle d accès sera nécessaire ; FileInfo : Cette valeur permet de modifier les différents types de fichiers utiliser par le serveur (ex : ErrorDocument). Elle ne devrait être utilisée qu avec un grand contrôle ; Indexes : Cette valeur permet de piloter l indexation des répertoires mais aussi de changer le nom du fichier recherché par défaut (index.html). Elle ne devrait être positionnée, qu à la demande des rédacteurs, dans les blocs où l affichage du contenu du répertoire sera nécessaire et contrôlé ; Limit : Cette valeur est nécessaire pour gérer les droits afférant aux autorisations. Elle devrait être positionnée à la demande des rédacteurs. Options :Cette valeur permettrait de positionner n importe quelle option du serveur comme active comme par exemple : l exécution de CGI et l utilisation de liens symboliques. Dangereuse pour la sécurité, elle ne devrait pas être utilisée Le fichier.htaccess Le nom, par défaut, de ce fichier est.htaccess. Il est défini par la directive : AccessFileName.htaccess Il est très important que l accès en soit interdit pour les utilisateurs du serveur Web. D autre part, l adresse (http ://servername/repertoireprotégé/.htaccess) ne doit pas retourner le fichier. Pour cela on utilise la directive Files tel que le montre l exemple. Une modification du nom de fichier par défaut.htaccess pour accroître la sécurité devrait s accompagner d une adaptation de la directive Files si son nouveau nom le requière (cf. figure 13). Remarque : Cet exemple protège aussi contre la divulgation d un fichier.htpasswd <Files ~ "^\.ht"> Order allow,deny Deny from all </Files> Fig. 13 Protection des fichiers en.ht Démarrer le service Le serveur Apache peut être démarré en «stand-alone», c est à dire qu il est lancé systématiquement et reste à l écoute en permanence. Il peut également être lancé par le biais du démon inetd ce qui correspond à un lancement «à la demande du client» du serveur. Pour des raisons de sécurité et de performance un serveur Apache dédié devrait toujours être lancé en «stand-alone». Ce mode est utilisé en général par défaut. On le vérifie dans httpd.conf (cf. figure 14). : 22 exemple : <Directory /> </Directory> constitue le bloc contenant les commandes valides, sauf redéfinition, pour l arborescence du site Web depuis la racine N /SGDN/DCSSI/SDO/BAS Page 37 sur 47

38 # # ServerType is either inetd, or standalone. # Inetd mode is only supported on Unix platforms. # ServerType standalone Fig. 14 définition du type de serveur Suppression des traces permettant d identifier le serveur Apache Lors de la création d une page d erreur le serveur Apache décline généralement son identité et sa version installée (cf. figure 15). Fig. 15 Message d erreur par défaut d un serveur Apache La suppression de cette trace présente par défaut se fait par modification, dans httpd.conf (cf. figure 16). # Set to one of: On Off # ServerSignature Off Fig. 16 Modification des traces Cette modification ne suffit pas, on peut aussi obtenir des informations en utilisant un telnet sur le port 80 (ou le port utilisé par le serveur Web) (cf. figure 17). telnet nicolasaudit.internet 80 Trying nicolasaudit.internet... Connected to adr.ip.server.web Escape character is ^]. HEAD / HTTP/1.0 HTTP/ Bad Request Date: Tue, 22 Oct :26:48 GMT Server: Apache/ (Unix) Debian GNU/Linux Connection: close Fig. 17 Traces obtenues par telnet N /SGDN/DCSSI/SDO/BAS Page 38 sur 47

39 La figure 17 laisse clairement apparaître que le serveur Web est un Server : Apache/ (Unix) Debian GNU/Linux. La suppression partielle de cette trace, présente par défaut, se fait, par modification, dans httpd.conf. ServerTokens Prod ATTENTION Cette ligne n existe, en général, pas dans le httpd.conf par défaut, il faut la créer ; Cette directive ne fonctionne que sur les serveurs Apache de version supérieure au (ServerTokens existe depuis la 1.3 mais sans l option Prod) ; Cette directive retire la version du produit mais il reste le nom : Apache. La seule possibilité d enlever complètement 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 " " Les modules Le fichier httpd.conf est souvent livré avec un grand nombre de modules actifs par défaut. Mettre un «#» devant la commande LoadModule permet de désactiver les fonctionnalités non nécessaires. Les modules présentés ci-après nécessitent une attention toute particulière. autoindex_module crée automatiquement la liste des fichiers présents dans un répertoire en l absence d un des fichiers par défaut, tel que index.html. Fig. 18 Exemple d index créé automatiquement par Apache Comme évoqué au l indexation automatique pourrait permettre à un attaquant potentiel de récupérer des informations auxquelles il n aurait pas dû avoir accès ; N /SGDN/DCSSI/SDO/BAS Page 39 sur 47

40 status_module permet d afficher des informations sur le serveur. Le module est actif par défaut. Les lignes mettant en place le lien http ://servername/server-status sont, en général, commentées ou inexistantes. Laisser le module actif, s il est inutilisé ne présente aucun intérêt (cf. figure 19). Apache Server Status for nicolasaudit.internet Server Version: Apache/ (Unix) Debian GNU/Linux Server Built: Aug :37:24 Current Time: Tuesday, 22-Oct :22:53 CEST Restart Time: Tuesday, 22-Oct :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: "_" 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 W 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/ Server at nicolasaudit.internet Port 80 Fig. 19 résultat de la requête http :// /server-status Les informations présentées dans la figure 19 faciliteraient grandement l attaque d un pirate. userdir_module permet à chaque utilisateur de la machine d avoir accès à tout ou partie de son répertoire personnel (UserDir public_html par défaut) au travers du serveur Web en utilisant une adresse du type(cf fig. 20) http ://servername/ũser. Le nombre d utilisateurs devant être réduit au minimum, sur un serveur Web dédié, ce module ne devrait pas rester actif ; N /SGDN/DCSSI/SDO/BAS Page 40 sur 47

41 Fig. 20 Exemple d accès à un répertoire partagé cgi_module permet l exécution de scripts sur le serveur. Un paragraphe traite des CGI ultérieurement dans ce document ( ) ; auth_module fournit le système d authentification de base d Apache. Lorsque ce module est utilisé les identifiants et mots de passe sont stockés et circule en clair. Il est préférable d utiliser mod_auth_digest Les CGI Les CGI sont des programmes exécutés par le serveur. A ce titre ils doivent être l objet de toutes les attentions. Si l on ne peut s en passer il faudrait Retirer tous les CGI livrés en exemple ; Les stocker hors de l arborescence des fichiers Web ; N autoriser l exécution de programme que dans ce répertoire ; Interdire toute modification de droit Apache dans ce répertoire ; Interdire toute modification de droit correspondant à l exécution de cgi sur la totalité de l arborescence ; Mettre en place une procédure de contrôle et validation de CGI avant leur mise en place sur le serveur Web (plus particulierement sur le filtrage des paramètres transmis par les utilisateurs du site). La figure 21 présente le chargement du module cgi, son répertoire d exploitation, les contraintes et restrictions mises sur ce répertoire ainsi que la suppression (par mise en commentaire) des associations 23 dangereuses. 23 handler N /SGDN/DCSSI/SDO/BAS Page 41 sur 47