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
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
Table des matières
1 Introduction 7
1.1 Objectifs des recommandations . . . 7
1.2 À qui sont destinées ces recommandations . . . 7
1.3 Structure de ce document . . . 7
1.4 Présentation des recommandations . . . 7
2 Avertissements 8 3 Pré-requis 9 3.1 Connaissances nécessaires . . . 9
3.2 Définition des rôles et tâches . . . 9
4 Principaux risques du serveur Web 10 4.1 Modification de contenu . . . 10
4.2 Arrêt ou dysfonctionnement du service Web . . . 10
4.3 Révélation d’information . . . 10
4.4 Servir de base d’attaque . . . 10
5 Politique générale de la sécurité des systèmes d’information 11 6 Principes fondamentaux de la SSI 12 6.1 Développer et implémenter une défense en profondeur . . . 12
6.1.1 La sécurité des locaux et la sûreté de fonctionnement . . . 12
6.1.1.1 Ce qu’il faut prendre en compte prioritairement sur les lots techniques 13 6.1.2 La défense au niveau du réseau . . . 15
6.1.2.1 Utilisation de commutateurs . . . 15
6.1.2.2 Mise en place d’outils de détection d’intrusion . . . 15
6.1.3 La défense au niveau des hôtes . . . 15
6.1.4 La défense au niveau des applications . . . 15
6.1.5 La défense au niveau des données . . . 15
6.2 Principe du moindre privilège . . . 16
7 Sécuriser : mesures générales 17 7.1 Relevé de configuration . . . 17
7.2 Préalables de l’installation . . . 17
7.2.1 Vérification du système sous-jacent . . . 17
7.2.2 Version du serveur Web à installer . . . 18
7.2.3 Vérification des sources d’installation . . . 18
7.2.3.1 Média physique . . . 18
7.2.3.2 Installation d’un applicatif téléchargé . . . 18
7.2.3.3 Installation directe depuis un réseau externe . . . 18
7.3 Installation . . . 19
7.4 Emploi de mots de passe complexes . . . 19
7.5 Administration du système . . . 20
7.5.1 Administration locale . . . 20
7.5.2 Administration distante . . . 20
7.5.2.1 Terminal Services . . . 20
7.5.2.2 SNMP . . . 21
7.5.2.3 Télémaintenance . . . 21
8 Sécuriser : mesures spécifiques 22 8.1 Sécuriser les systèmes d’exploitation . . . 22
8.1.1 Installation du système d’exploitation . . . 22
8.1.2 Configuration du système d’exploitation . . . 22
8.1.3 Anti-virus . . . 22
8.2 Sécuriser l’environnement réseau . . . 22
8.2.1 Adapter et contrôler la configuration du pare-feu . . . 22
8.3 Sécuriser le serveur Web . . . 23
8.3.1 Mesures génériques de sécurisation d’un serveur Web . . . 23
8.3.1.1 Gestion des utilisateurs . . . 23
8.3.1.2 Procédures de validation des modifications ou mises à jour . . . . 23
8.3.1.3 Procédures de mise à jour du contenu du site . . . 23
8.3.1.4 Restrictions de droits . . . 24
8.3.1.5 Organisation adéquate du contenu . . . 24
8.3.1.6 Activation du chiffrement SSL . . . 24
8.3.1.7 Banalisation du serveur . . . 25
8.3.1.8 Limitation des fonctionnalités du site au stricte nécessaire . . . 25
8.3.1.9 Sécurisation de l’administration à distance . . . 25
8.3.2 Sécuriser le serveur IIS . . . 25
8.3.2.1 Limiter l’installation au minimum de services . . . 26
8.3.2.2 Méthode d’authentification . . . 26
8.3.2.3 Positionner les droits sur les répertoires virtuels du serveur . . . . 27
8.3.2.4 Définir les droits sur les fichiers journaux . . . 27
8.3.2.5 Activer et configurer les journaux du serveur Web . . . 27
8.3.2.6 Restriction d’accès par adresses IP ou nom DNS . . . 28
8.3.2.7 Supprimer les tiers de confiance de la configuration Internet . . . 28
8.3.2.8 Les pages d’enregistrement de Certificate Server . . . 28
8.3.2.9 Le service d’indexation . . . 29
8.3.2.10 Supprimer toutes les documentations, pages et applications d’exemples 29 8.3.2.11 Supprimer tous les liaisons inutiles . . . 29
8.3.2.12 Supprimer le support RDS . . . 30
8.3.2.13 Contrôle du contenu des champs de formulaire . . . 30
8.3.2.14 Désactiver l’affichage de contenu de répertoire . . . 30
8.3.2.15 Editer toutes les pages d’erreurs . . . 31
8.3.2.16 Invalider l’utilisation du répertoire parent . . . 31
8.3.2.17 Désactiver l’appel au shell de commande avec #exec . . . 31
8.3.2.18 Désactiver l’adresse IP dans l’entête (Content-Location) . . . 31
8.3.2.19 Mettre en place un filtrage des requêtes, sécurisation globale d’IIS 32 8.3.3 Sécuriser le serveur Apache . . . 32
8.3.3.1 Les utilisateurs . . . 32
8.3.3.2 Les fichiers . . . 34
8.3.3.3 Modification des droits par les rédacteurs : le fichier .htaccess . . . 36
8.3.3.4 Démarrer le service . . . 37
8.3.3.5 Suppression des traces permettant d’identifier le serveur Apache . 38 8.3.3.6 Les modules . . . 39
8.3.3.7 Les CGI . . . 41
8.3.3.8 Les liens symboliques . . . 42
9 Maintenir le niveau de sécurité : mesures générales 43 9.1 Règles d’exploitation . . . 43
9.1.1 Gestion des correctifs de sécurité (serveurs et clients) . . . 43
9.1.2 Réalisation de fiches réflexes pour gérer les alertes . . . 43
9.1.3 Formation . . . 43
9.1.4 Gestion des comptes et des mots de passe . . . 43
9.1.5 Serveur de secours et de test . . . 44
9.1.6 Gestion des sauvegardes . . . 44
9.1.7 Gestion des éléments temporaires . . . 44
9.2 Mise à jour de la PSSI . . . 44
9.3 Audits de sécurité . . . 44
10 Maintenir le niveau de sécurité : mesures spécifiques 45 10.1 Exploitation des journaux . . . 45
10.2 Réaliser une veille technologique sur les éléments du réseau . . . 45
10.3 Autres paragraphes . . . 45
Glossaire 46
Index 47
Table des figures
1 analyse de /etc/passwd . . . 33
2 analyse de /etc/group . . . 33
3 résultat de la commande PS (serveur Web démarrer) . . . 33
4 analyse de /etc/shadow . . . 33
5 Droits sur le fichier httpd.conf et le répertoire apache . . . 34
6 Configuration dans httpd.conf du nom du fichier de redéfinition des droits . . . 34
7 Choix du répertoire contenant les données du serveur Web. . . 34
8 Droits sur les fichiers et repertoires du serveur Web. . . 35
9 Choix du répertoire contenant les CGI. . . 35
10 Droits d’accès aux CGI. . . 36
11 Balise de journalisation . . . 36
12 Droits d’accès aux journaux . . . 36
13 Protection des fichiers en .ht . . . 37
14 définition du type de serveur . . . 38
15 Message d’erreur par défaut d’un serveur Apache . . . 38
16 Modification des traces . . . 38
17 Traces obtenues par telnet . . . 38
18 Exemple d’index créé automatiquement par Apache . . . 39
19 résultat de la requête http ://127.0.0.1/server-status . . . 40
20 Exemple d’accès à un répertoire partagé . . . 41
21 Exemple de configuration de CGI . . . 42
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 guiden’est pas un guide d’administra- tion 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 à conser- ver 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.
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 docu- ment 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 75700 Paris 07 SP
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 confi- guration sont nécessaires pour l’application des recommandations détaillées. Une connaissance du protocole HTTP1est 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.
1Hyper Text Transfer Protocol RFC 2068
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ésinfor- mation, 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.
5 Politique générale de la sécurité des systèmes d’in- formation
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,www.ssi.gouv.fr) pour plus d’informations sur l’établissement d’une PSSI.
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 (in- formation, 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.
6.1.1 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éna- gement 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 effondre- ments, . . . ;
– 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 (vibra- tions)), . . . ;
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 plu- viales, 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.
6.1.1.1 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 :
6.1.1.1.1 Énergie électrique
Le local accueillant le poste de transformation MT/BT (Moyenne Tension/Basse Tension) doit, si possible, être implanté sur le site tout en laissant un 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’on- duleurs, . . .) 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, . . .).
6.1.1.1.2 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.
6.1.1.1.3 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
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 eux- mêmes devant être refroidis. Pour cela, des échangeurs thermiques (aérothermes) protégés en mal- veillance (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.
6.1.1.1.4 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 (ondu- leurs, 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’ac- tivation 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.
6.1.1.1.5 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.
6.1.1.1.6 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.
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, infra- rouge...) 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.
6.1.2 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).
6.1.2.1 Utilisation de commutateurs
La mise en place d’un environnement réseau sécurisé passe par la mise en œuvre de com- mutateurs bien administrés. En effet si l’on se passe de commutateurs 3 et que l’on utilise des concentrateurs4, 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 recom- mandé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.
6.1.2.2 Mise en place d’outils de détection d’intrusion 6.1.3 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.
6.1.4 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.
6.1.5 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 trans- mises 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 »
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.
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 dis- tinguant 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 9.1.1 page 43.
7.2 Préalables de l’installation
7.2.1 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érieu- rement 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.
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.
7.2.3 Vérification des sources d’installation
Lors de l’installation d’un élément logiciel (système d’exploitation ou applicatif) sur une ma- chine, 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é.
7.2.3.1 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 mali- cieux 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.
7.2.3.2 Installation d’un applicatif téléchargé
La problématique reste la même que pour un support physique. Il convient toujours d’effec- tuer 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 cryp- tographiques 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.
7.2.3.3 Installation directe depuis un réseau externe
Cette approche est à proscrire absolument car il ne vous est laissé aucune possibilité de person- naliser 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.
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 fonc- tion 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 :
– http://www.microsoft.com/TechNet/security/default.asp
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épara- tion 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 ap- puyant sur ALT et NB, où NB est un nombre compris entre 1 et 255 pour les environnements Windows.
– 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 appli- cation 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 passemé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’authentifica- tion 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
7.5.1 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.
7.5.2 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.
7.5.2.1 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 administra- teur peut donc gérer un serveur à distance. Il est recommandé d’utiliser les fonctions de chiffrement
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.
7.5.2.2 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).
7.5.2.3 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.
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.
8.1.1 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.
8.1.2 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ée5.) ;
– placer les répertoires qui contiendront les fichiers journaux dans un espace de taille suffisante.
8.1.3 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.
8.2.1 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 »
8.3 Sécuriser le serveur Web
8.3.1 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.
8.3.1.1 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’IGC6(PKI7) ;
8.3.1.2 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.
8.3.1.3 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’ap- plication de toute mise à jour importante.
6Infrastructure de Gestion de Clés
7Public Key Infrastructure
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).
8.3.1.4 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.
8.3.1.5 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 exclusi- vement 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.
8.3.1.6 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 confiden- tialité 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 chif- frement 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.
8Secure Socket Layer
Un autre inconvénient du SSL (et de tout chiffrement de bout en bout) peut résider dans le fait que nombre d’IDS9ne 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.
8.3.1.7 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.
8.3.1.8 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.
8.3.1.9 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 ;
– . . .
8.3.2 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 souhai- table que l’administrateur système ai au préalable appliqué les recommandations de sécurisation du système correspondant.
9Intrusion 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.
8.3.2.1 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
8.3.2.2 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 pos- sible 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 inter- actifs ou participatifs (forums de discussion, . . .) , et de serveur avec un besoin de confidentialité ou de restriction d’accès.
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’iden- tifiants 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 éven- tuels 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.
8.3.2.3 Positionner les droits sur les répertoires virtuels du serveur
Comme il a été expliqué précédemment au chapitre 8.3.1.5, 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.
8.3.2.4 Définir les droits sur les fichiers journaux
les fichiers journaux (log) du serveur IIS (%systemroot%\system32\Logfiles ) doivent avoir les ACL10 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.
8.3.2.5 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 étendu11. 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 .
10Access 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.
11Format 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)
