Mise en place d’outils de détection d’intrusion

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’installarépara-tion 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ée⁵.) ;

– 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

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