Recommandations de sécurisation serveur Web - Issy les Moulineaux, le n /SGDN/DCSSI/SDO/BAS
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
PREMIER MINISTRE
Secrétariat général Issy les Moulineaux, le
de la défense
nationale n◦ /SGDN/DCSSI/SDO/BAS
Direction centrale de la
sécurité des systèmes
d’information
Recommandations de sécurisation
serveur WebRecommandations 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
N◦ /SGDN/DCSSI/SDO/BAS Page 2 sur 47Recommandations de sécurisation – serveur Web
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
N◦ /SGDN/DCSSI/SDO/BAS Page 3 sur 47Recommandations de sécurisation – serveur Web
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
N◦ /SGDN/DCSSI/SDO/BAS Page 4 sur 47Recommandations de sécurisation – serveur Web
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
N◦ /SGDN/DCSSI/SDO/BAS Page 5 sur 47Recommandations de sécurisation – serveur Web
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
N◦ /SGDN/DCSSI/SDO/BAS Page 6 sur 47Recommandations de sécurisation – serveur Web
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’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.
N◦ /SGDN/DCSSI/SDO/BAS Page 7 sur 47Recommandations de sécurisation – serveur Web
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
N◦ /SGDN/DCSSI/SDO/BAS Page 8 sur 47Recommandations de sécurisation – serveur Web
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 HTTP1 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 47Recommandations de sécurisation – serveur Web
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.
N◦ /SGDN/DCSSI/SDO/BAS Page 10 sur 47Recommandations de sécurisation – serveur Web
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.
N◦ /SGDN/DCSSI/SDO/BAS Page 11 sur 47Recommandations de sécurisation – serveur Web
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.
N◦ /SGDN/DCSSI/SDO/BAS Page 12 sur 47Recommandations de sécurisation – serveur Web
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
N◦ /SGDN/DCSSI/SDO/BAS Page 13 sur 47Recommandations de sécurisation – serveur Web
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.
N◦ /SGDN/DCSSI/SDO/BAS Page 14 sur 47Recommandations de sécurisation – serveur Web
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
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 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 »
N◦ /SGDN/DCSSI/SDO/BAS Page 15 sur 47Recommandations de sécurisation – serveur Web
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 47Recommandations de sécurisation – serveur Web
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.
N◦ /SGDN/DCSSI/SDO/BAS Page 17 sur 47Recommandations de sécurisation – serveur Web
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.
N◦ /SGDN/DCSSI/SDO/BAS Page 18 sur 47Recommandations de sécurisation – serveur Web
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.
N◦ /SGDN/DCSSI/SDO/BAS Page 19 sur 47Vous pouvez aussi lire
