Guide Messagerie

PREMIER MINISTRE
Secrtariat gnral de la dfense nationale
Issy les Moulineaux, le n /SGDN/DCSSI/SDO/BAS
Direction centrale de la scurit des systmes dinformation
Recommandations de scurisation Messagerie
Informations
Nombre de pages du document : 46
Evolution du document : Version 0.1 Rdaction Cline Estieux Validation DCSSI Philippe Brandt Date
N /SGDN/DCSSI/SDO/BAS
Page 2 sur 46
Table des matires

1 Introduction 1.1 1.2 1.3 1.4 2 3 Objectifs des recommandations . . . . . . . qui sont destines ces recommandations Structure de ce document . . . . . . . . . . Prsentation des recommandations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 7 7 7 8 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9 9 9 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10 10 11 11 11 11 12 13 13 13 14 16 16 16 16 16 16 17 18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 18 18 19 19 19 19 19 20
Avertissements Pr-requis 3.1 3.2 3.3 Matriels . . . . . . . . . . . . . . . . . . . . . . . . . Connaissances ncessaires . . . . . . . . . . . . . . . Standards utiliss pour la messagerie lectronique 3.3.1 Structure dun message lectronique . . . . . . . . .
Principaux risques de la messagerie 4.1 4.2 4.3 4.4 4.5 4.6 4.7 Rception/Envoi de virii . . . . . . . . . . . . . Rception/Envoi messages falsis . . . . . . . Lecture de messages par de tierces personnes Relais pour des messages extrieurs . . . . . . Perte de messages . . . . . . . . . . . . . . . . . Indisponibilit du serveur de messagerie . . . Rebond possible pour une attaque en interne
5 6
Politique gnrale de la scurit des systmes dinformation Principes fondamentaux de la SSI 6.1 Dvelopper et implmenter une dfense en profondeur . . . . . . . . . . 6.1.1 La scurit des locaux et la sret de fonctionnement . . . . . . . . . . . . . 6.1.1.1 Ce quil faut prendre en compte prioritairement sur les lots techniques 6.1.2 La dfense au niveau du rseau . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.2.1 Utilisation de commutateurs . . . . . . . . . . . . . . . . . . . . . 6.1.2.2 Mise en place doutils de dtection dintrusion . . . . . . . . . . . 6.1.3 La dfense au niveau des htes . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.4 La dfense au niveau des applications . . . . . . . . . . . . . . . . . . . . . 6.1.5 La dfense au niveau des donnes . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Principe du moindre privilge . . . . . . . . . . . . . . . . . . . . . . . . . Scuriser : mesures gnrales 7.1 7.2 Relev de conguration . . . . . . . . . . . . . . . . . . Pralables de linstallation . . . . . . . . . . . . . . . . 7.2.1 Vrication du systme sous-jacent . . . . . . . . . . . 7.2.2 Version du serveur de la messagerie installer . . . . . 7.2.3 Vrication des sources dinstallation . . . . . . . . . . 7.2.3.1 Mdia physique . . . . . . . . . . . . . . . . 7.2.3.2 Installation dun applicatif tlcharg . . . . 7.2.3.3 Installation directe depuis un rseau externe 7.3 Installation . . . . . . . . . . . . . . . . . . . . . . . . .
Page 3 sur 46
7.4 7.5
Emploi de mots de passe complexes . . . . . Administration du systme . . . . . . . . . . . 7.5.1 Administration locale . . . . . . . . . . . . . 7.5.2 Administration distante . . . . . . . . . . . . 7.5.2.1 Terminal Services . . . . . . . . . . 7.5.2.2 SNMP . . . . . . . . . . . . . . . . 7.5.2.3 Tlmaintenance . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20 21 21 21 21 22 22 23 23 23 24 24 25 26 26 26 26 26 27 27 27 28 28 28 28 28 28 28 29 29 29 30 30 31 31 32 32 32 32 32 35 38
Scuriser : mesures spcifiques 8.1 Scuriser lenvironnement rseau . . . . . . . . . . . . . . . . . . . . . . . 8.1.1 Mise en place dune architecture scurise . . . . . . . . . . . . . . . . . . . 8.1.2 Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.2.1 Positionnement et fonctionnement de lantivirus . . . . . . . . . . 8.1.3 Adapter et contrler la conguration du pare-feu . . . . . . . . . . . . . . . 8.1.4 Installation de tunnels chirants . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Scuriser le systme dexploitation . . . . . . . . . . . . . . . . . . . . . . 8.2.1 Installation du systme dexploitation . . . . . . . . . . . . . . . . . . . . . 8.2.1.1 Choix des serveurs de messagerie . . . . . . . . . . . . . . . . . . . 8.2.1.2 Disques et partitionnement du serveur de messagerie . . . . . . . . 8.2.1.3 Suppression de la documentation sur le serveur . . . . . . . . . . . 8.2.1.4 Conguration des journaux . . . . . . . . . . . . . . . . . . . . . . 8.2.2 Conguration du systme dexploitation . . . . . . . . . . . . . . . . . . . . 8.3 Scuriser les postes des utilisateurs . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Sensibilisation des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1.1 Non-divulgation de message contenant des informations sensibles sur Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1.2 Prserver la rputation dune entit . . . . . . . . . . . . . . . . . 8.3.1.3 Ne pas perturber la disponibilit du serveur de messagerie . . . . 8.3.1.4 Utiliser un programme de scurisation des messages lectroniques 8.3.2 Antivirus des clients de messagerie . . . . . . . . . . . . . . . . . . . . . . . 8.3.3 Conguration des programmes de messagerie . . . . . . . . . . . . . . . . . 8.3.4 Verrouillage de la conguration des postes . . . . . . . . . . . . . . . . . . . 8.3.5 Utilisation de mots de passe complexes . . . . . . . . . . . . . . . . . . . . . 8.3.6 Utilisation de programmes client de scurisation des messages lectroniques 8.3.6.1 Standards utiliss pour le chirement des messages lectroniques . 8.3.6.2 Choix dun programme de scurisation . . . . . . . . . . . . . . . 8.3.7 Systme daccs aux messages lectroniques via un navigateur Internet . . . 8.4 Scuriser les serveurs de la messagerie . . . . . . . . . . . . . . . . . . . . 8.4.1 Conguration des serveurs de messagerie . . . . . . . . . . . . . . . . . . . . 8.4.1.1 Excution du programme sous un utilisateur possdant des droits rduits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.1.2 Suppression des commandes inutiles sur le serveur de messagerie . 8.4.1.3 Suppression des traces permettant didentier le serveur de messagerie 8.4.1.4 Mise en place de protocoles de scurisation adapts . . . . . . . . Maintenir le niveau de scurit : mesures gnrales 9.1 Rgles dexploitation . . . . . . . . . . . . . . . . . . . 9.1.1 Gestion des correctifs de scurit (serveurs et clients) . 9.1.2 Ralisation de ches rexes pour grer les alertes . . 9.1.3 Formation . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.4 Gestion des comptes et des mots de passe . . . . . . . 9.1.5 Serveur de secours et de test . . . . . . . . . . . . . . 9.1.6 Gestion des sauvegardes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38 38 38 38 38 39 39
Page 4 sur 46
9.2 9.3 10
9.1.7 Gestion des lments temporaires . . . . . . . . . . . . . . . . . . . . . . . . Mise jour de la PSSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Audits de scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39 39 39 40 40 40 40 41 41 41 41 41 41 41 42 42 42 42 42 42 42 42 43 43 43 43 43 43 44 44 44 45 45 46 46
Maintenir le niveau de scurit : mesures spcifiques 10.1 Exploitation des journaux . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Raliser une veille technologique sur les lments du rseau . . . . . . 10.3 Veille technologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Annexes 11.1 Points vrier gnraux . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.1 Mesures gnrales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Environnement rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.3 Systme dexploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.3.1 Installation du systme dexploitation . . . . . . . . . . . . . . . . 11.1.3.2 Conguration du systme dexploitation . . . . . . . . . . . . . . . 11.1.3.3 Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.4 Postes des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.4.1 Installation des clients de messagerie . . . . . . . . . . . . . . . . . 11.1.4.2 Conguration des clients de messagerie . . . . . . . . . . . . . . . 11.1.4.3 Programmes de scurisation des clients de messagerie . . . . . . . 11.1.5 Serveurs de messagerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.5.1 Conguration du serveur . . . . . . . . . . . . . . . . . . . . . . . 11.1.5.2 Extensions de scurit . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Points vrier pour Microsoft Exchange 5.5 . . . . . . . . . . . . . . . 11.2.1 Avertissement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.2.1 Pr-installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.2.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.2.3 Post-installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.3 Administration des composants Exchange . . . . . . . . . . . . . . . . . . . 11.2.3.1 Annuaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.3.2 Banque dinformations . . . . . . . . . . . . . . . . . . . . . . . . 11.2.3.3 Agent de transfert des messages . . . . . . . . . . . . . . . . . . . 11.2.4 Congurer le service messagerie Internet (SMTP) . . . . . . . . . . . . . . . 11.2.5 POP/IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.6 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Page 5 sur 46
Table des figures

1 2 3 4 5 6 7 Exemple darchitecture scurise . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table des ux de pare-feu pour la messagerie . . . . . . . . . . . . . . . . . . . . . Liste dextensions supportes par le serveur ESMTP domaine.exemple . . . . . . . Informations rvles lors dune connexion un serveur de messagerie . . . . . . . Informations rvles lors dune connexion un autre serveur de messagerie . . . . Informations rvles dans lentte dun message lectronique . . . . . . . . . . . . Informations sur larchitecture et les machines rvles dans lentte dun message lectronique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 26 33 33 33 34 35
Page 6 sur 46
1
1.1
Introduction
Objectifs des recommandations
Ce guide a pour vocation daider scuriser la messagerie laide de recommandations bases sur ltat de lart.
1.2
qui sont destines ces recommandations
Ces recommandations sont destines principalement aux administrateurs, responsables de la scurit des systmes dinformation et en gnral toute personne ou organisation voulant scuriser ou vrier la scurisation de la messagerie. En particulier ce guide nest pas un guide dadministration de la messagerie.
1.3
Structure de ce document
Ce document est scind en plusieurs parties : Partie 1 : introduction gnrale aux recommandations ; Partie 2 : mise en garde sur lapplication de ces recommandations ; Partie 4 : relev non exhaustif des principales vulnrabilits lies la messagerie ; Partie 5 : rappel non technique sur lorganisation de la scurit dun systme dinformation ; Partie 6 : rappel des principes fondamentaux de la scurit dun systme dinformation ; Partie 7 : recommandations gnrales sur la scurisation dun systme dinformation et de serveurs ; Partie 8 : recommandations spciques la scurisation de la messagerie ne mettre en oeuvre quune fois, linstallation du systme ou lors de la premire mise en application de ce document ; Partie 9 : recommandations gnrales sur les oprations mener pour conserver un bon niveau de scurisation dans le temps ; Partie 10 : recommandations sur les oprations spciques la messagerie destines conserver un bon niveau de scurisation dans le temps ; Partie 11 : lments techniques complmentaires, comme des listes de contrle.
1.4
Prsentation des recommandations
Les recommandations de scurisation sont scindes en deux phases : Scuriser (Partie 7 et Partie 8) : recommandations mettre en uvre une seule fois, linstallation du systme ou lors de la premire mise en application de ce document ; Maintenir la scurit (Partie 9 et Partie 10) : recommandations suivre tout au long de la vie de la messagerie pour sassurer que le niveau de scurit reste constant dans le temps. De plus, chacune de ces phases contient deux parties, ddies aux mesures gnrales et aux mesures spciques participant lobjectif nal.
Page 7 sur 46
Avertissements
La responsabilit du choix et de la mise en oeuvre des recommandations proposes dans ce document incombe au lecteur de ce guide. Il pourra sappuyer sur la politique de scurit du systme dinformation et sur les rsultats dune analyse des risques de la scurit des systmes dinformation pour dterminer les recommandations les plus pertinentes. Le lecteur devra galement raliser des tests exhaustifs an de vrier ladquation de ces recommandations avec son contexte particulier. Vu la nature volutive des systmes dinformation et des menaces portant sur ceux-ci, ce document prsente un savoir-faire un instant donn et a pour ambition dtre rgulirement amlior et complt. Vos commentaires sont les bienvenus. Vous pouvez les adresser ladresse postale suivante : Bureau Audits en SSI SGDN/DCSSI/SDO/BAS 51, boulevard de la Tour-Maubourg 75700 Paris 07 SP
Page 8 sur 46
3
3.1 3.2
Pr-requis
Matriels Connaissances ncessaires
Le lecteur devra tre familier avec la notion de rseau, et connatre les protocoles suivants : SMTP et POP (ou IMAP).
3.3
3.3.1
Standards utiliss pour la messagerie lectronique

Structure dun message lectronique
Le message lectronique se compose de deux parties distinctes spares par au moins une ligne vide : lentte ; le corps du message. Lentte comporte nombre dinformations utiles lenvironnement de lexpditeur ainsi que le chemin suivi par le message : expditeur, destinataire, date, priorit, serveurs utiliss pour le transit, sujet du message, . . . Le corps du message contient quant lui le contenu du message proprement parler.
Page 9 sur 46
Principaux risques de la messagerie

Dans cette partie seront dcrits les principaux risques lis la messagerie.
4.1
Rception/Envoi de virii
La rception de virii est un problme trs souvent voqu par les administrateurs rseau. En eet, la messagerie lectronique permet de vhiculer tous les types de chiers, en particulier les scripts et les chiers excutables. Si ces programmes sont excuts sur la machine qui a reu le courrier, un virus est susceptible dinfecter la machine. Cependant si les administrateurs pensent frquemment se protger de la rception de virii pour ne pas contaminer le rseau interne, lmission de virii nest que peu souvent voque. Il est pourtant vital de se protger galement contre lmission de virii. En eet lmission de virii peut bien videmment contaminer les autres, ce qui ne devrait pas arriver, mais peut aussi nuire gravement limage de marque dune entit et engendrer un dni de service. Cest pourquoi les deux aspects de la protection virale (mission et rception doivent tre mis en uvre.
4.2
Rception/Envoi messages falsis
Le protocole standard le plus utilis pour la messagerie lectronique est SMTP. Cependant ce protocole ne prsente, dans sa fonction de base, i. e. la plus rpandue, aucune garantie contre la falsication des messages lectroniques. Il ny a par exemple aucun contrle eectu sur lexpditeur du message, et par consquent nimporte qui sur le mme rseau peut se faire passer pour quelquun dautre. Il ny a ainsi aucune garantie quant lexpditeur du message avec un message envoy via SMTP. De la mme manire, le contenu mme des messages peut tre falsi. Il convient donc de se prmunir contre la rception et lenvoi de messages falsis en utilisant les mthodes dcrites dans la suite de ce document.
4.3
Lecture de messages par de tierces personnes
Une autre faiblesse du protocole SMTP rside dans le fait que les messages envoys ou reus par ce biais sont transmis en clair sur le rseau, cest dire quils ne sont pas chirs. Ainsi, toute personne coutant sur le rseau a la possibilit de voir le contenu du message1 , identier le contenu du message et galement lentte du message lectronique2 . On peut se prmunir de ce problme en envoyant une pice jointe chire, mais il faut garder lesprit quavec cette mthode, lentte reste transmis en clair, avec toutes les informations cites prcdemment. Le protocole POP3 est un protocole standard trs utilis pour aller retirer des messages lectroniques sur un serveur. Il nest utilis quasiment que dans sa mise en oeuvre basique, cest--dire sans scurit aucune. Pour rappel, son mode de fonctionnement est le suivant : un utilisateur sauthentie au serveur en envoyant son nom dutilisateur et son mot de passe, qui circulent en clair sur le rseau, puis le serveur envoie les messages requis lutilisateur, toujours en clair. Quelquun coutant sur le rseau ce moment donn aura ainsi la possibilit de lire tous les messages, au format dcrit prcdemment (cf. partie 3.3.1), circulant sur le rseau au moment de son coute. Mais il pourra galement, et cest une chose dont il conviendra de se prmunir fortement, rcuprer le nom et le mot de passe de lutilisateur cout pour prendre connaissance ultrieurement de ses messages son insu et galement essayer son mot de passe pour dautres applications que la messagerie lectronique.
1 voir 2
exemple de message lectronique gure 7 titre de rappel, lentte comprend entre autres lexpditeur, le destinataire, et le sujet du message.
Page 10 sur 46
4.4
Relais pour des messages extrieurs
Une architecture scurise de rseau comprend gnralement au moins deux serveurs de messagerie : un serveur interne au rseau, et un relais de messagerie servant uniquement de passerelle, envoyant des messages provenant du serveur interne vers lextrieur et rceptionnant les messages provenant de lextrieur en attendant la connexion du serveur interne pour rcuprer les messages. On voit ainsi que le serveur relais de messagerie est le plus proche des rseaux extrieurs, et sa scurit devrait tre particulirement tudie. Il ne devrait avoir que deux fonctions : transmettre des messages en provenance ou destination du rseau local ; il ne devrait donc en aucun cas pouvoir servir de relais de messagerie entre deux rseaux extrieurs. Si ctait le cas, le serveur faisant oce de relais pourrait servir pour relayer des messages linsu de ladministrateur, tels lenvoi massif de publicit ( spam ) et les administrateurs de ce serveur pourraient tre poursuivis pour avoir permis la diusion de ce type de messages.
4.5
Perte de messages
Un serveur de messagerie, que ce soit en relais ou en serveur interne, doit tre bien dimensionn et bien scuris pour rsister la charge et des attaques en dni de service qui conduiraient des pertes de messages. Ce risque doit tre pris en considration, car une perte de message lectronique est aujourdhui trs dicilement accepte par les utilisateurs. Il faut galement penser la conguration du serveur antivirus sil existe, car si ce serveur est mal congur, il pourrait refuser et supprimer des messages contamins sans en informer lexpditeur et/ou le destinataire et galement refuser des messages non-contamins.
4.6
Indisponibilit du serveur de messagerie
Si le serveur de messagerie est la cible dattaques en dni de service, il peut tre indisponible pendant une longue dure. Lindisponibilit peut tre due par exemple une saturation du serveur par un grand nombre de messages envoys volontairement (attaque cible dun pirate), par un ou plusieurs messages envoys un nombre de destinataires lev. Lattaque peut galement provenir par exemple de lenvoi de messages infects ou de messages rsultant de lenvoi dune chane de solidarit.
4.7
Rebond possible pour une attaque en interne
Un serveur de messagerie peut tre situ en zone protge (dans une DMZ ou sur le rseau interne). Il est ainsi possible quil dispose de privilges supplmentaires par rapport un attaquant situ dans une zone non protge (Internet par exemple). Si ce serveur de messagerie est compromis, il pourra potentiellement servir de rebond pour une attaque destination dune machine dans un rseau scuris qui naurait pu tre ralise autrement.
Page 11 sur 46
Politique gnrale de la scurit des systmes dinformation
Un document, la politique de scurit dun SI (Systme dInformation) doit exister au sein de lorganisme mettant en uvre le SI. Parmi les rgles relatives la scurisation de la messagerie prsentes dans la PSSI, on doit retrouver au moins les lments ci-dessous : la fonctionnalit du composant au sein du SI ; la liste des comptes dadministration ainsi que les modalits de gestion de ces comptes dans le temps ; la liste des ux entrants/sortants vers/depuis le composant ; la liste des services lancs au dmarrage ; la liste des services audits et leurs chiers ; le suivi des mises jour des versions des logiciels utiliss ; une copie des chiers de conguration de tous les services et des chiers de dmarrage ; les mesures de scurit physique mises en place ; la liste des correctifs et des modications ralises sur le composant ; les oprations dexploitation mettre en uvre sur le composant. Les recommandations nonces dans tout ce document devraient galement trouver leur place dans les rgles de cette PSSI. Le lecteur pourra se reporter au document dit par la DCSSI Guide pour llaboration dune Politique de Scurit Interne (disponible sur le site internet de la DCSSI, www.ssi.gouv.fr) pour plus dinformations sur ltablissement dune PSSI.
Page 12 sur 46
6
6.1
Principes fondamentaux de la SSI

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

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

Scuriser lenvironnement rseau
Mise en place dune architecture scurise
Lorsquune interconnexion du rseau interne avec Internet est prsente, une architecture scurise devrait tre mise en place an de ne pas laisser de portes dentre un attaquant potentiel. Cette architecture devrait comporter deux serveurs de messagerie minimum pour limiter les risques dattaques. Si cette architecture est mise en place, le premier serveur est positionn au niveau de la zone dmilitarise (DMZ) et sert de relais pour envoyer ou recevoir les mails de lextrieur. Le deuxime serveur est positionn dans le rseau local et il est congur pour ne communiquer quavec le serveur de messagerie relais situ sur la DMZ. Un tel exemple darchitecture est insr dans ce guide. (gure 1).
Fig. 1 Exemple darchitecture scurise Chaque serveur de messagerie devrait tre redond pour empcher une interruption de service dun serveur de messagerie qui pourrait tre intentionnelle ou accidentelle. Il est galement recommand de scuriser les lments annexes du rseau ncessaires un bon fonctionnement des serveurs de messagerie, tels les serveurs de noms (DNS).
Page 23 sur 46
8.1.2
Antivirus
Un premier antivirus devrait tre mis en place pour contrler le ux global de messages lectroniques (son positionnement exact sera discut dans la suite de ce document) et un second antivirus sur les postes clients des utilisateurs. Le premier antivirus sera appel antivirus de serveur de messagerie dans ce document et le second antivirus des clients de messagerie . Ces antivirus devront tre de technologie dirente an de rduire les risques ; en eet si un virus nest pas dtect par le premier antivirus, il le sera peut-tre par le second, ce qui augmentera les chances de dtection. Dautre part, les deux types dantivirus (ux et postes) sont complmentaires : par exemple lantivirus de serveur de messagerie ne peut pas analyser les messages chirs, mais les antivirus des clients de messagerie le peuvent car pour lire les messages, il faut que les utilisateurs les dchirent sur leurs postes. Les antivirus devraient tre mis jour rgulirement si lon veut obtenir une scurit relle. Une solution de mise jour automatique pourrait ventuellement tre envisage pour lantivirus de serveur si les ressources en interne ne permettent pas une validation pralable. Il faut cependant bien garder lesprit que cette mise jour est une porte dentre pour une attaque potentielle. Il y a dj eu par le pass des attaques par ce biais. La solution de mise jour automatique ne doit tre envisage quen dernier recours. Sur les postes des utilisateurs, la mise jour de lantivirus des clients de messagerie devrait quant elle tre faite automatiquement et ne pas ncessiter le recours des utilisateurs. Il faut bien garder lesprit que lorsque lon a choisi de mettre en uvre une protection antivirale, celle-ci est ncessaire pour les ux entrants et sortants comme il a dj t prcis au paragraphe 4.1. Dautre part, il convient de bien se rappeler que cette protection nest pas totale et que lon nest jamais labri dun virus non encore reconnu par les antivirus ou encore cr spciquement pour attaquer une entit prcise. Cependant, la quasi-totalit des attaques virales sont repousses par un antivirus bien congur et mis jour quotidiennement. Des informations concernant les virus et antivirus sont disponibles sur le site du CERTA (http ://www.certa.ssi.gouv.fr), en particulier les documents suivants : http ://www.certa.ssi.gouv.fr/site/CERTA-2000-INF-007 ; http ://www.certa.ssi.gouv.fr/site/CERTA-2001-ALE-012. 8.1.2.1 Positionnement et fonctionnement de lantivirus
Lantivirus de serveur de messagerie peut tre positionn deux endroits dirents (cf. gure 1) : sur le serveur relais de messagerie ; sur le serveur interne de messagerie. La meilleure solution serait bien videmment de positionner un antivirus sur chacun des serveurs. Les avantages et inconvnients du choix de lune de ces solutions seront tout de mme dcrits ici pour rpondre aux besoins de ceux qui nauraient pas les moyens dinstaller plusieurs antivirus de serveur. Cependant, la solution dinstaller lantivirus de serveur de messagerie sur le pare-feu ne devrait pas tre envisage. Lutilisation de service mandataire (proxy) ddi lanalyse antivirale ne ferait que surcharger le pare-feu. 8.1.2.1.1 Sur le serveur relais de messagerie
Lorsque lon place lantivirus de serveur de messagerie sur le serveur relais, le processus est le suivant : le serveur de messagerie coute sur le port 25 (SMTP), reoit les messages provenant de lextrieur ou du serveur interne, analyse les messages, et sil ne trouve pas de virus, fait suivre le message vers son destinataire. Le message ne devrait pas tre dlivr sil y a un virus et pas simplement tre nettoy puis envoy6 . Dautre part, on ne devra pas envoyer de message davertissement
6 En eet, certains virus analysent tout le carnet dadresses de la personne contamine et envoient un message chacune des personnes du carnet dadresses, ce qui peut provoquer une monte en charge du serveur de messagerie.
Page 24 sur 46
lmetteur du message pour linformer que celui-ci contenait un virus, car lmetteur du message peut avoir t falsi. Le serveur de relais intercepte ainsi les messages infects avant leur introduction sur le rseau interne, cependant ce serveur est considrablement ralenti car chaque message est analys. Pour de meilleures performances, il peut tre envisag de faire tourner le serveur antivirus sur une machine ddie dans la DMZ. Pour rsumer, les avantages sont les suivants : arrt du virus avant sa pntration dans le rseau interne ; non-modication du serveur de messagerie interne. Et les inconvnients sont les suivants : modication du serveur relais de messagerie ; ralentissement du serveur relais de messagerie ; non-analyse via cet antivirus des messages circulant en interne (messages provenant du rseau interne et destins en mme temps ce rseau) ; rejet par erreur de certains messages ; installation dun service supplmentaire qui a ses propres vulnrabilits. 8.1.2.1.2 Sur le serveur interne de messagerie
La deuxime possibilit est de placer lantivirus de serveur de messagerie sur le serveur interne de messagerie. Le processus utilis est le mme que celui du serveur relais dcrit prcdemment et les mmes prcautions devraient tre prises, savoir supprimer le message infect, avertir lexpditeur et envisager linstallation sur une machine ddie pour de meilleures performances. Cette solution est dautant plus envisager que le serveur interne est souvent beaucoup plus charg que le serveur relais. En installant lantivirus de serveur de messagerie sur le serveur interne de messagerie, on remdie linconvnient principal de la solution de lintgration au serveur relais, cest--dire que lon peut se protger des messages venant et allant vers des utilisateurs internes. Pour rsumer, les avantages sont les suivants : protection contre les messages infects venant et allant vers lintrieur du rseau ; non-modication du serveur relais de messagerie. Et les inconvnients sont les suivants : modication du serveur interne de messagerie ; ralentissement du serveur interne de messagerie ; rejet par erreur de certains messages ; installation dun service supplmentaire qui a ses propres vulnrabilits. 8.1.3 Adapter et contrler la conguration du pare-feu
Les pare-feux devraient bien videmment tre congurs en prenant garde de nautoriser que les ux ncessaires et bien identis. Il faudrait pour cela rdiger un tableau des ux passant travers les pare-feux et congurer les pare-feux en fonction de ces ux. En prenant lexemple de la gure 1, et en supposant que les serveurs de messagerie fonctionnent tous deux en SMTP et en POP pour le serveur interne, on obtient le tableau suivant pour les pare-feux, en supposant que celui-ci est de type stateful (cf. gure 2). Ici seuls les ux SMTP et POP ont t pris en compte. A cela il faut galement ajouter les ux DNS, etc. et aussi les ux scuriss des protocoles prcdemment cits si ceux-ci sont utiliss (SSMTP, POP3S, . . .)
Page 25 sur 46
Pare-feu FW-A FW-A FW-A FW-A FW-B FW-B
Interface dpart 1 2 3 3 6 6
Interface arrive 2 1 2 2 4 4
Protocole TCP TCP TCP TCP TCP TCP
Port dpart >1024 >1024 >1024 >1024 >1024 >1024
Port arrive 25 25 25 110 110 25
Fig. 2 Table des ux de pare-feu pour la messagerie
8.1.4
Installation de tunnels chirants
Les protocoles de messagerie les plus utiliss i. e. SMTP, POP et IMAP ne sont absolument pas scuriss dans leur version par dfaut. Ils laissent par exemple tout le trac passer en clair entre les direntes machines. Ceci peut tre amlior en modiant ces protocoles, mais cela ncessite gnralement des modications substantielles des serveurs de messagerie (cf. partie 8.4.1.4). Une alternative envisageable pourrait tre dinstaller des tunnels chirants entre toutes les machines ou les dirents serveurs. Le minimum serait, si lon choisit loption des tunnels chirants, de mettre en oeuvre ce tunnel entre les deux serveurs de messagerie : le serveur interne et le serveur relais. Cependant, il faut savoir quainsi le trac passe toujours en clair entre les machines client et le serveur. Quelquun coutant le trac sur le rseau interne peut toujours lire les messages envoys, reus, ainsi que les mots de passe POP transitant sur le rseau. Pour contrer ce risque, il faudrait donc mettre en oeuvre le protocole choisi sur chaque poste. On pourrait par exemple installer des tunnels IPSec sur les direntes machines (A titre dexemple, ce protocole est disponible par dfaut dans Windows 2000 et ses versions postrieures ; si cette solution est choisie, ce protocole est une bonne solution car cest un standard prenne.).
8.2
Scuriser le systme dexploitation
Pour scuriser un serveur de messagerie, il faudrait appliquer les recommandations dcrites ci-dessous qui sont indispensables pour une bonne scurisation du serveur mais ce ne sera pas susant, car il faut galement congurer correctement le systme dexploitation prsent. Pour cela il faudra consulter les recommandations de scurisation appropries dans les guides spciques aux systmes dexploitation. 8.2.1 Installation du systme dexploitation
Un systme devrait tre scuris ds son installation et donc ne pas attendre quil soit dploy pour le scuriser. Il est en eet beaucoup plus coteux et dicile de scuriser un serveur une fois quil a t congur et dploy. 8.2.1.1 Choix des serveurs de messagerie
Le choix des serveurs de messagerie est souvent dterminant pour le choix du systme dexploitation associ. Cependant si cela est possible, le systme dexploitation devrait tre choisi pour tre le plus scuris possible. Il devrait donc tre le moins vulnrable aux direntes attaques possibles, congurable le plus prcisment possible, tre capable de limiter laccs des utilisateurs aux informations adquates, pouvoir restreindre le lancement des applications aux utilisateurs et rpertoires adapts, journaliser les vnements, etc. Les comptences du personnel ne devraient pas tre oublies, il devra en eet tre form ce systme dexploitation. 8.2.1.2 Disques et partitionnement du serveur de messagerie
Lors de linstallation du systme dexploitation, un disque physique ou au moins une partition dirente devrait tre install pour les chiers contenant les botes aux lettres des utilisateurs.
Page 26 sur 46
Ce disque devrait tre dirent du disque utilis pour le systme dexploitation et le systme du serveur de messagerie, ainsi en cas de saturation du disque par les messages des utilisateurs, les donnes systmes et applicatives ne seront pas corrompues. Dautre part, il pourrait tre ncessaire dinstaller lapplication serveur de messagerie sur une partition dirente de la partition systme. En eet la partition systme, si elle est bien congure, a des droits restrictifs ne permettant pas lutilisation dun serveur de messagerie. Et enn, les chiers journaux ncessiteront eux-aussi un disque physique dirent ou au moins une partition dirente pour viter la saturation du disque en cas dattaque en dni de service. 8.2.1.3 Suppression de la documentation sur le serveur
Lorsque lon installe un serveur de messagerie, on installe gnralement la documentation avec ce serveur pour pouvoir comprendre tous les paramtres de conguration de ce serveur et avoir rapidement accs ces informations. Cette documentation est trs utile pour linstallation, mais une fois que le serveur est oprationnel, cette documentation ne devrait plus rester sur la machine en question. En eet si un pirate russit sintroduire sur le serveur, il aura a sa disposition toutes les informations utiles pour recongurer le serveur directement. 8.2.1.4 Conguration des journaux
Les journaux devraient tre congurs pour rcuprer le plus grand nombre dinformations pertinentes. En particulier on nauditera pas que les checs mais galement les russites dvnements, ce qui permet de voir si une tentative dintrusion a russi. De plus, les journaux du serveur de messagerie devraient tre placs dans des rpertoires de taille susante. Des informations sur la conguration des journaux sont dcrites dans les guides spciques sur les systmes dexploitation. Il faut cependant garder lesprit que nombre de serveurs de messagerie permettent, dans les options de journalisation les plus compltes, de journaliser le contenu des messages lectroniques passant par ces serveurs de messagerie. Or ce sont des donnes nominatives qui doivent faire lobjet dune dclaration la CNIL et qui doivent tre extrmement bien protges car les responsabilits sont grandes. 8.2.2 Conguration du systme dexploitation
Une fois que le systme dexploitation a t install de la faon la plus scurise possible, il conviendrait de le congurer soigneusement an de pallier aux risques potentiels. Si le systme dexploitation a t choisi comme dcrit prcdemment, il pourra permettre de positionner correctement un grand nombre de paramtres : permissions des chiers, limitation des utilisateurs, etc. Les permissions devraient ainsi tre positionnes de manire trs scurise an de permettre aux utilisateurs et aux applications de naccder quaux donnes qui leur sont absolument ncessaires. En particulier il faudrait veiller aux permissions des chiers suivants : chiers de conguration des applicatifs et du systme ; chiers contenant des mots de passe chirs ; chiers contenant des cls de chirement ; journaux du serveur ; chiers contenant les droits daccs aux dirents chiers ; botes aux lettres des utilisateurs. Laccs du serveur de la messagerie devrait galement tre limit un certain nombre de chiers : le serveur de messagerie peut crire des chiers journaux mais il ne devrait pas avoir les droits pour lire ces mmes chiers ; les chiers temporaires devraient tre restreints un rpertoire spcique bien protg qui ne sera accessible qu lutilisateur qui a cr ces chiers.
Page 27 sur 46
Les droits et permissions des utilisateurs devraient eux aussi tre bien grs ainsi que ceux de lapplicatif du serveur de messagerie. En particulier si lon est sous un systme de type Unix, on installera le serveur dans une arborescence conne7 .
8.3
8.3.1
Scuriser les postes des utilisateurs

Sensibilisation des utilisateurs Non-divulgation de message contenant des informations sensibles sur Internet
8.3.1.1
Sensibiliser les utilisateurs sur ce point devrait tre une action prioritaire. En eet, beaucoup ne se rendent pas compte que leur message circule en clair sur Internet et quil est de ce fait susceptible dtre lu par nimporte qui. Il est essentiel de leur faire comprendre dune part que la messagerie lectronique classique nest absolument pas scurise (pas dauthentication, pas de chirement, les mots de passe POP et IMAP peuvent passer en clair, . . .), et dautre part que sur Internet on ne doit pas faire circuler dinformations sensibles. 8.3.1.2 Prserver la rputation dune entit
Lenvoi de messages provenant dune entit spcique contenant des virii peut nuire sa rputation. Cest galement le cas si les utilisateurs envoient des messages condentiels via Internet. En sensibilisant les utilisateurs ce problme, on peut esprer rduire signicativement ce risque. 8.3.1.3 Ne pas perturber la disponibilit du serveur de messagerie
Si les utilisateurs contribuent relayer des messages inutiles tels des chanes de solidarit , des faux virus, des canulars par messagerie8 , le fonctionnement du serveur peut tre perturb et cela peut aller jusqu altrer sa disponibilit. Ceci peut galement arriver si les utilisateurs envoient rgulirement des messages trs volumineux, en particulier sils sont compresss et que les serveurs dantivirus les dcompressent avant de les analyser. 8.3.1.4 Utiliser un programme de scurisation des messages lectroniques
Si le choix a t fait demployer un tel programme (cf. partie 8.3.6), les utilisateurs devraient tre sensibiliss au maniement de celui-ci pour apprendre lutiliser correctement. Ils devraient en eet connatre les principes lmentaires mis en uvre (chirement, signature, authentication) et surtout savoir comment appliquer ces principes pour envoyer un message scuris. 8.3.2 Antivirus des clients de messagerie
Pour une scurisation complte de tous les lments, linstallation dun antivirus devrait tre gnralise sur tous les postes clients. Ces antivirus devraient ainsi tre congurs pour analyser les messages partant du poste et arrivant sur le poste des utilisateurs. Ces antivirus devraient galement agir lorsque les utilisateurs ouvrent les messsages et pices jointes. Dautre part, ces antivirus sont utiles pour la messagerie mais galement pour tous les chiers potentiellement contamins prsents sur la machine des utilisateurs (rapatriement par disquette par exemple, ce qui est un risque non ngligeable). Ces antivirus devraient tre mis rgulirement jour par ladministrateur, sans intervention des utilisateurs et ne devraient pas pouvoir tre dsactivs par les utilisateurs.
appele chroot site http ://www.hoaxbuster.com peut tre un lien intressant pour la sensibilisation car il permet de vrier si un message est un canular ( hoax ) ou non. De plus amples informations sur ce sujet peuvent tre trouves dans lavis du CERTA CERTA-2000-INF-005.
8 Le 7 galement
Page 28 sur 46
8.3.3
Conguration des programmes de messagerie
Un des points les plus importants pour la scurisation des postes des utilisateurs devrait tre de sassurer que les clients de messagerie utiliss sont bien installs dans leur version la plus stable et dote des derniers correctifs de scurit. En eet, la grande majorit de ces clients de messagerie disposent de nombreux correctifs supprimant les dernires vulnrabilits. Ces correctifs sont tlchargeables depuis les sites des clients de messagerie lectronique (cf. partie 10.3) en respectant les prcautions lmentaires (cf. partie 7.2.3.2). Dautre part, ces clients de messagerie lectronique ne sont pas toujours congurs par dfaut avec la conguration la plus scurise. Il faudrait en eet sassurer que les points suivants ont bien t congurs sur les clients de messagerie : la visualisation automatique du message ne devrait pas tre active ; louverture automatique du message suivant ne devrait pas non plus tre active ; lexcution automatique des pices jointes ne devrait pas tre activ ; lenvoi des messages ne devrait seectuer quen texte clair et non en HTML ; lexcution automatique de contenu du message ne devrait pas tre active. En eet si lon reoit des pages HTML, avec du contenu actif tels des contrles ActiveX, des scripts JavaScript ou tout autre code mobile, ce contenu ne devra pas sexcuter lorsque lon lit la page car les virus sont bien souvent propags par ce biais. 8.3.4 Verrouillage de la conguration des postes
La conguration dcrite dans la partie prcdente devrait tre eective sur tous les postes des utilisateurs, mais le problme est de sassurer que les utilisateurs conservent bien cette conguration sur leur machine et quils ne la changent pas. Cela devrait tre fait, car on constate souvent que les utilisateurs changent leurs paramtres pour plus de facilit et de convivialit et bien rarement pour plus de scurit. Des utilitaires sont ainsi proposs par certains diteurs de clients de messagerie (par exemple Outlook Express et Netscape Messenger) pour ger la conguration des clients en une image bien particulire que les utilisateurs ne pourront pas modier. Cela est fait en amont : les administrateurs congurent le client de messagerie et ventuellement le navigateur selon les options quils ont choisies, ils dploient ensuite une version du client de messagerie modie sur tous les postes et ainsi les utilisateurs nont accs quaux options que leur administrateur rseau a bien voulu leur coner. Cet utilitaire est gratuit pour les solutions Microsoft. Cette solution devrait tre gnralise sur tous les postes des utilisateurs. 8.3.5 Utilisation de mots de passe complexes
Dans la messagerie lectronique comme ailleurs, les mots de passe sont un point de passage oblig pour scuriser correctement un systme. Cest en eet gnralement un gros point faible du systme car les utilisateurs ont du mal choisir un mot de passe complexe. Ils sont donc dautant plus vulnrables lcoute de leurs messages lectroniques, que leur mot de passe est faible. De bonnes rgles de choix dun mot de passe sont dcrites dans la partie 7.4. En particulier le mot de passe choisi devrait tre dirent des autres mots de passe. En eet, comme le protocole POP laisse passer les noms de compte et les mots de passe en clair, il serait trs facile pour un attaquant de rcuprer le mot de passe et de le tester sur les autres systmes. Cependant, si le serveur de messagerie est bien scuris (cf. partie 8.4, ce serveur ne doit pas permettre de rcuperer les mots de passe via le protocole POP standard, mais via des protocoles de rcupration scurises (APOP, Kerberos/POP, TLS/SSL, . . .). Il est ainsi absolument ncessaire que les clients de messagerie supportent le protocole choisi.
Page 29 sur 46
8.3.6
Utilisation de programmes client de scurisation des messages lectroniques
tant donn que les messages lectroniques passent en clair avec les protocoles de messagerie usuels (SMTP, POP et IMAP sans extension de scurit), une solution de scurisation possible est dinstaller sur les postes des utilisateurs des programmes auxiliaires de chirement. Cette solution permet ainsi dassurer des fonctions de scurit lmentaires (authentication, intgrit, condentialit, . . .) pour la messagerie lectronique. Les avantages de cette solution sont les suivants : pas de modication des serveurs de messagerie existants (ni ceux en interne, ni les externes par lesquels passent des messages) ; possibilit daner la solution selon les besoins (chirement et/ou signature) ; scurisation des messages destination ou en provenance de correspondants extrieurs, devant passer dans une zone non sre (Internet) sil existe le mme quipement cryptographique chez ces correspondants et en interne ; condentialit du message du poste metteur jusquau poste rcepteur. Les inconvnients de cette solution sont les suivants : choix dune solution qui devra tre interoprable avec le maximum dutilisateurs ; ncessit de prsence dun quipement similaire lautre bout de la chane ; ncessit de former tous les utilisateurs lutilisation de la solution choisie ; dploiement dune politique de gestion des cls (asymtriques ou non) ; inecacit des antivirus de serveurs analyser le contenu de ces messages. 8.3.6.1 Standards utiliss pour le chirement des messages lectroniques
Les deux mcanismes les plus rpandus sont les standards S/MIME et OpenPGP. Ces standards sont dcrits dans ce document titre dexemple, mais il existe nombre dalgorithmes sur le march permettant de scuriser la messagerie lectronique. 8.3.6.1.1 Description des mcanismes mis en uvre
Ces deux standards reposent en partie sur le principe de cryptographie cls asymtriques. Chaque utilisateur possde deux cls : une cl prive (ou cl secrte) connue de lui seul et une cl publique quil peut donner nimporte qui. La cl publique du destinataire est utilise pour envoyer des informations chires que seul le destinataire pourra dchirer en utilisant sa cl prive. La cl prive de lexpditeur sert envoyer des informations dont lauthenticit sera vrie avec la cl publique de lexpditeur, connue de tous. En ralit le message complet nest pas sign, mais cest un condensat du message cr partir du message lui-mme. Dautre part, des algorithmes de cryptographie cl symtrique (ou partage) sont galement utiliss dans le processus de scurisation des messages lectroniques, pour des raisons de rapidit de traitement essentiellement. Typiquement, le processus de chirement est le suivant : lexpditeur gnre une cl de session symtrique alatoire ; lexpditeur chire le message en utilisant cette cl alatoire avec un algorithme cl symtrique ; lexpditeur chire la cl de session avec la cl publique du destinataire du message ; lexpditeur envoie son message chir et la cl de session chire au destinataire ; le destinataire dchire la cl de session avec sa cl prive et ensuite son message avec la cl de session. On peut ainsi tre quasiment assur que seul le destinataire peut dchirer le message. En ralit, le nombre de cls est limit et donc il existe une probabilit quune autre personne dtienne la mme cl, et puisse dchirer le message. Cependant cette probabilit est extrmement faible.
Page 30 sur 46
8.3.6.1.2
Non-chirement des enttes
Il faut savoir que les programmes utilisateur de scurisation de la messagerie lectronique ne traitent que le corps du message9 , et jamais lentte. Ainsi si on envoie un message chir avec un sujet trs explicite, celui ci circulera en clair, ainsi que dautres informations comme lexpditeur, le destinataire... Il faut bien garder lesprit que mme ces informations (expditeur et destinataire ainsi que tout champ de lentte) peuvent tre sensibles. Lors de lenvoi dun message, une prcaution lmentaire serait de sassurer quaucune information sensible ne soit contenue dans lentte du message.10 8.3.6.1.3 Usages multiples
Ces programmes se prtent diverses utilisations : lauthentication, le chirement, lintgrit et la non-rpudiation et on peut distinguer deux types de prestation oerte par ces programmes : la signature lectronique et le chirement. Pour la signature lectronique, le message lectronique envoy est toujours transmis en clair, mais un condensat est envoy en mme temps que le message lectronique au destinataire : cest la signature lectronique. Cette signature est cense11 garantir plusieurs choses : que lmetteur du message est bien celui qui a sign le message lectronique (authentication), que le contenu du message na pas t falsi (intgrit), et que lmetteur du message est bien le seul avoir pu lmettre (non-rpudiation). Pour le chirement, le corps du message est chir et envoy lexpditeur. Le besoin couvert est bien sr la condentialit. On voit ainsi que pour rpondre tous les besoins il faudra signer et chirer le message. 8.3.6.2 Choix dun programme de scurisation
Lorsque lon a choisi dinstaller un programme de scurisation des messages lectroniques pour les utilisateurs, une rexion devrait tre mene an de savoir quelle application choisir pour rpondre au mieux ses besoins. La scurit est bien videmment primordiale pour dterminer ce choix. Le programme choisi devrait disposer dun algorithme susamment robuste ainsi quune puissance de chirement leve, tout en respectant la lgislation en vigueur12 . Le programme devrait galement pouvoir tre utilis facilement et rapidement par les utilisateurs, tout en respectant les rgles de scurit classiques, comme le stockage de la cl prive sur une machine dconnecte du rseau. Cependant, si la contrainte est trop forte pour eux, ils contourneront la scurisation de leurs messages lectroniques. Il faudra donc choisir un programme adapt, et galement assurer une formation aux utilisateurs. Il faudrait galement choisir une solution susamment prenne et interoprable pour pouvoir communiquer de manire scurise avec le plus grand nombre de correspondants extrieurs. 8.3.7 Systme daccs aux messages lectroniques via un navigateur Internet
On peut choisir dutiliser un serveur Internet permettant aux utilisateurs daccder leurs messages lectroniques et de les envoyer depuis un navigateur. La conguration dun tel serveur ncessite bien videmment la scurisation du systme dexploitation et du serveur Web install sur ce serveur (cf. guides DCSSI appropris). Nanmoins, il faudrait faire attention nautoriser que des connexions SSL/TLS 128 bits minimum. En eet comme pour les protocoles SMTP et POP, par dfaut la consultation des messages
partie 3.3.1 pour connatre la structure dun message lectronique sr les traces inutiles laisses dans lentte comme par exemple le champ X-Mailer devront tre supprimes avant dacheminer le message (cf. partie 8.4.1.3.3 11 En ralit, ce qui est garanti, cest que si la signature ne correspond pas, le message na pas t sign par la bonne personne ou quil a t modi. Une personne tierce pourrait trs bien, thoriquement, signer ce message avec sa propre signature, et la signature pourrait tre identique. Cette probabilit est cependant susamment faible pour tre considre comme improbable. 12 cf. documentation adquate, en particulier http ://www.ssi.gouv.fr/reglementation/regl_crypto.html
10 Bien 9 cf.
Page 31 sur 46
lectroniques sur un navigateur nest absolument pas scurise, tout passe en clair : identiants, mots de passe, messages. Avec le protocole SSL/TLS les connexions seront authenties et chires de lmetteur vers le serveur dans le cas dun envoi de messages et du serveur vers le destinataire dans le cas dune rception de messages. Cependant, il nest pas garanti que lmission et la rception du message se fasse via ce protocole scuris. Pour cette raison, on pourrait donc coupler cette solution avec lutilisation de programmes utilisateur de chirement.
8.4
8.4.1
Scuriser les serveurs de la messagerie

Conguration des serveurs de messagerie Excution du programme sous un utilisateur possdant des droits rduits
8.4.1.1
Le serveur de messagerie devrait tre lanc sous un utilisateur ddi appartenant un groupe ddi. Cet utilisateur et ce groupe ne devraient pas servir autre chose. De plus, sous un systme de type Unix, cet utilisateur ne devrait pas possder dinvite de commandes13 valide et lon ne doit pas pouvoir se connecter sous cet utilisateur. Pour tre dmarr et donc ouvrir le serveur sur les ports ncessaires, il pourrait tre ncessaire dinitialiser le serveur avec le compte Administrateur ou root. Cependant, lutilisation de ce compte devrait tre limite au lancement du serveur ; en eet ce compte passe le relais au compte ddi possdant bien videmment beaucoup moins de droits que le compte Administrateur ou root, il possde en fait uniquement les droits ncessaires son bon fonctionnement. 8.4.1.2 Suppression des commandes inutiles sur le serveur de messagerie
Lorsque lon installe un serveur de messagerie, son installation par dfaut comporte gnralement bon nombre de commandes inutiles son bon fonctionnement et qui peuvent mme rduire signicativement le niveau de scurit. Ces commandes devraient donc tre dsactives pour assurer un bon niveau de scurit du serveur de messagerie. Deux commandes permettent de tester si une adresse est valide : EXPN et VRFY. Si ces commandes sont actives sur le serveur, un attaquant peut se constituer une liste de tous les comptes crs sur cette machine pouvant recevoir des messages lectroniques. La commande DEBUG permet de dboguer le serveur de messagerie ; elle ne devrait donc pas rester active dans ce serveur. Cette commande permet dobtenir de nombreuses informations sur le comportement et la conguration du serveur de messagerie. Il faudrait donc vrier que le serveur de messagerie na pas t compil avec cette option active. Plus gnralement, toute commande non ncessaire au bon fonctionnement du serveur de messagerie devrait tre dsactive. En particulier, lorsque lon se connecte via ESMTP14 un serveur de messagerie, aprs la commande EHLO on peut rcuprer la liste de toutes les extensions supportes. Un exemple de ces informations est donn la gure 3. On peut voir sur cette gure que la liste dextensions est trs longue. On peut ainsi reprer lextension VRFY qui devrait tre dsactive. 8.4.1.3 Suppression des traces permettant didentier le serveur de messagerie
De nombreuses mthodes permettent de rcuprer des informations sur les serveurs de messagerie installs. En eet, ces serveurs donnent beaucoup trop dinformations lorsque lon les contacte. Ils peuvent ainsi rvler leur type, leur numro de version, les correctifs installs, . . . Ces informations ne devraient pas tre rvles car elles sont totalement superues et servent uniquement renseigner un ventuel pirate. Il faut cependant garder lesprit que ces mthodes ne servent qu retarder une attaque et non pas la contrer.
13 galement 14 Extended
appele shell SMTP : extension du protocole SMTP
Page 32 sur 46
220 domaine.exemple ESMTP Server ready EHLO toto 250-domaine.exemple Hello [192.168.7.7] 250-TURN 250-ATRN 250-SIZE 5242880 250-ETRN 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-BINARYMIME 250-CHUNKING 250-VRFY 250-X-LINK2STATE 250-XEXCH50 250 OK QUIT 221 2.0.0 domaine.exemple Service closing transmission channel Connection closed by foreign host. Fig. 3 Liste dextensions supportes par le serveur ESMTP domaine.exemple 8.4.1.3.1 Identit et version du serveur rvles directement par la connexion sur le port 25 du serveur
Par exemple, lors de la connexion sur le port 25 du serveur de messagerie, ce serveur dcline gnralement son identit et sa version . Un exemple de ces informations est donn aux gures 4 et 5. telnet 127.0.0.1 25 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is ^]. 220 pc.test ESMTP Exim 3.35 #1 Thu, 20 Jun 2002 21:35:20 +0200 Fig. 4 Informations rvles lors dune connexion un serveur de messagerie Trying 192.168.7.7... Connected to domaine.exemple Escape character is ^]. 220 domaine.exemple ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2650.13) ready Fig. 5 Informations rvles lors dune connexion un autre serveur de messagerie On voit la gure 4 que lon est en prsence dun serveur de messagerie EXIM, dont la version est la 3.35. Et la gure 5, on voit que lon aaire un serveur Microsoft Exchange. On connat mme sa version complte savoir 5.5.2650.13, le serveur est donc un Exchange version 5.5 avec le SP3. En laissant sacher le numro de version, un pirate pourra ainsi cibler son attaque en fonction de la version du serveur, du service pack install, des correctifs et du type de serveur rencontr. Ici, il saura que le service pack 4 na pas t install et quil peut donc tenter des attaques bien particulires. Il conviendrait donc de ltrer ces informations et de ne rien laisser passer qui puisse rvler facilement lidentit du serveur de messagerie. Cependant le serveur pourra peut-tre tre identi
Page 33 sur 46
cause des lments supports, des rponses aux requtes, etc. Ces informations permettent de retarder une attaque et de ltrer les attaques les plus triviales. 8.4.1.3.2 Extensions propritaires mises lors dun dialogue avec un serveur ESMTP
Un autre moyen de rcuprer des informations sur le serveur de messagerie est danalyser les extensions renvoyes par la commande EHLO sur un serveur ESMTP. Les extensions standard sont susceptibles dtre lances par tous les serveurs, mais les extensions commenant par X sont des extensions non standardises et beaucoup sont propritaires, ce qui permet didentier le type de serveur de messagerie. Par exemple lextension XEXCH50 que lon peut voir la gure 3 indique que cest un serveur Exchange. Autre exemple, lextension XUSR rvle gnralement un serveur Sendmail. Toutes ces extensions devraient donc tre supprimes si elles ne sont pas explicitement utiles. 8.4.1.3.3 Traces laisses dans les enttes de messages lectroniques permettant de rcuprer des informations sur le serveur de messagerie
De nombreuses traces sont laisses dans lentte des messages passant par certains serveurs de messagerie. Par exemple, lors de lenvoi dun message lectronique, il est frquent que le serveur employ pour la transmission du message inscrive des informations permettant de lidentier dans lentte du message lectronique transmis. Dautres informations peuvent galement tre inscrites, comme ladresse IP ou le systme dexploitation sous lequel tourne le serveur de messagerie. Un exemple dentte dun message lectronique est donn la gure 6. From personne@domaine.exemple Thu Jun 20 21:42:00 2002 Return-path: <personne@domaine.exemple> Envelope-to: celine@localhost Received: from localhost ([127.0.0.1] helo=serveur_messagerie) by pc.test with esmtp (Exim 3.35 #1 (Debian)) id 17L7nC-0000CE-00 for <celine@localhost>; Thu, 20 Jun 2002 21:41:09 +0200 From: Personne <personne@domaine.exemple> To: Celine <celine@localhost> Subject: Message de test Message-Id: <E17L7nC-0000CE-00@pc.test> Date: Thu, 20 Jun 2002 21:41:09 +0200 Fig. 6 Informations rvles dans lentte dun message lectronique Dans cet exemple (gure 6), on voit le serveur et sa version, savoir EXIM version 3.3.5 pour Debian, apparatre dans le corps du message. On peut de la mme manire que prcdemment cibler les attaques en fonction du type de serveur et de sa version, et galement de son systme dexploitation puisque lon voit ici apparatre une information supplmentaire, cest--dire que le serveur fonctionne sous Debian. Ces traces devraient donc tre supprimes de lentte de tous les messages lectroniques partant de lentit. 8.4.1.3.4 Traces laisses dans les enttes de messages lectroniques permettant de rcuprer des informations sur larchitecture
Si lon a une architecture avec plusieurs serveurs de messagerie, des informations supplmentaires sur le plan dadressage peuvent tre rvles. On peut ainsi la gure suivante (gure 7) reprer un grand nombre dinformations : sur la machine cliente : son client de messagerie et sa version : de Microsoft Outlook Express 5.50.4522.1200,
Page 34 sur 46
son adresse IP et son nom : 10.251.4.134, charles ; sur le serveur interne de messagerie : son nom DNS : serveur-exchange.ministere-essai.gouv.exemple, son adresse IP : 10.251.4.7, son type et sa version : Microsoft ESMTP Server v5.5.1789.3223 ; sur la passerelle de messagerie : son nom DNS : passerelle-postx.ministere-essai.gouv.exemple, son adresse IP : 10.1.2.3, son type : Postx (que lon aurait pu deviner partir du nom DNS) ; On peut ainsi voir que le rseau interne a vraisemblablement une traduction dadresse car toutes les adresses internes sont en 10.251.4.x, et que la passerelle de messagerie Postx a une adresse extrieure en 10.251.4.134. Dautre part, comme le client de messagerie est un Outlook Express, on peut facilement deviner que le systme dexploitation est un systme de Microsoft. En eet, si cela avait t un Outlook Express pour Macintosh, linformation aurait t crite dans lentte (champ X-Mailer dirent). Return-Path: <charles.martin@ministere-essai.gouv.exemple> Received: from passerelle-postfix.ministere-essai.gouv.exemple (10.1.2.3) by mel.domaine.exemple; 24 Jun 2002 16:24:38 +0200 Received: from serveur-exchange.ministere-essai.gouv.exemple (10.251.4.7) by passerelle-postfix.ministere-essai.gouv.exemple (Postfix); Mon, 24 Jun 2002 16:24:38 +0200 Received: from charles ([10.251.4.134]) by serveur-exchange.ministere-essai.gouv.exemple (Microsoft ESMTP Server v5.5.1789.3223); Mon, 24 Jun 2002 14:24:14 GMT From: Charles Martin <charles.martin@ministere-essai.gouv.exemple> To: Marc Dupont <marc.dupont@domaine.exemple> Subject: Envoi de message Date: Mon, 24 Jun 2002 17:48:52 +0200 Organization: Service du ministre de lessai MIME-Version: 1.0 Content-Type: text/plain X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Message Fig. 7 Informations sur larchitecture et les machines rvles dans lentte dun message lectronique Pour ne pas rvler trop dlments un attaquant potentiel, les enttes de tous les messages lectroniques mis par lentit devraient tre nettoyes de tous les champs permettant de rcuprer des informations sur cette identit. Dans le cas dune architecture plusieurs niveaux comme celle dcrite plus haut (avec au moins un serveur relais de messagerie sur la passerelle dinterconnexion et un serveur de messagerie en interne), lpuration de lentte des messages pourra se faire au dernier niveau avant dtre envoy, cest--dire au niveau de la passerelle. Ceci permet ainsi de ne faire quune puration (gain de temps), et permet galement de nettoyer les traces si le serveur interne ne le permet pas (par exemple, Microsoft Exchange ne le permet pas). 8.4.1.4 Mise en place de protocoles de scurisation adapts
Pour parer aux risques manant des protocoles de messagerie, des extensions scurises ont t dveloppes et sont dsormais intgres la plupart des serveurs de messagerie. Ces extensions sont des standards et leur utilisation est dautant plus recommande.
Page 35 sur 46
8.4.1.4.1
STARTTLS
Lextension la plus connue est STARTTLS15 qui permet une forte amlioration de la scurit de SMTP en assurant les points suivants : authentication forte des serveurs SMTP (via un certicat) ; tablissement dune session TLS (chire) entre 2 serveurs ; authentication forte des clients SMTP (via un certicat) ; tablissement dune session TLS (chire) entre le client et le serveur.
Avec lauthentication des serveurs SMTP par des certicats, on a la garantie que llment communiquant (client ou serveur) remet le courrier au vritable serveur et donc que son courrier nest pas dtourn vers un autre serveur. Dautre part, avec lauthentication des serveurs SMTP par des certicats, on peut tablir une session chire avec TLS. Ainsi tout le trac passant entre le serveur quip du certicat et lautre extrmit (client de messagerie ou autre serveur) est chire. On voit ainsi quavec cette solution, tout le trac interne de messagerie peut tre protg des coutes en munissant son serveur interne et sa passerelle de lextension STARTTLS. Dautre part, ceci peut tre trs pratique si lon a des postes nomades amens se connecter au serveur de messagerie dune entit travers Internet, car leurs communications seront galement chires. Si lon a plusieurs sites distants relis par une zone non sre (par exemple Internet), choisir lextension STARTTLS est la meilleure solution. Cependant, pour le dialogue avec des entits extrieures non contrles (et donc passant par des serveurs de messagerie externe), le chirement de bout en bout nest pas forcment assur car il nest pas garanti que le serveur distant supporte lextension TLS. Il ne faut surtout pas hsiter dployer cette solution car cest une solution simple dployer et qui permet un chirement complet. En eet loppos des solutions de chirement utilisateur, tout le message est chir, y compris les enttes. Enn, avec lutilisation de certicats pour les clients, on peut sassurer que seuls les utilisateurs ou serveurs dment autoriss pourront se connecter au serveur de messagerie. Ceci supprimera ainsi les problmes de relais de courrier non sollicit16 . Cependant, si lon utilise cette extension en dployant des certicats, il faut bien garder lesprit quune solution base dinfrastructure de gestion de cls (IGC) devra tre mise en place, soit en interne, soit en externe. La solution interne serait privilgier car elle permet une meilleure matrise de la scurit. Cette solution est galement possible pour les serveurs IMAP et POP17 . Si lextension nest pas encore supporte dans tous les types de serveurs, une encapsulation TLS peut tre ralise via un systme de tunnel18 . 8.4.1.4.2 Authentication du client de messagerie vis--vis du serveur
Beaucoup de serveurs proposent dsormais une authentication du client pour lenvoi des messages (SMTP19 ) an de ne pas envoyer de mails de la part dutilisateurs non autoriss. Cette option est trs utile pour viter, par exemple, de recevoir des mails falsis provenant de personnes malintentionnes se faisant passer pour des utilisateurs internes, ce qui est trs facilement ralisable avec un paramtrage classique (sans authentication) du serveur de messagerie. De la mme manire, plusieurs types dauthentication sont proposes par le serveur de messagerie pour la rception des messages lectroniques. On pourra ainsi envoyer le nom dutilisateur et le mot de passe en clair ou non (par exemple sous la forme dun condensat MD520 , mais galement avec tous les types dauthentication SASL21 supports par le serveur utilis22 ). Les solutions base de chirement sont bien videmment les solutions recommandes. Pour la mise en place
15 cf.
RFC2487 appel spam 17 cf. RFC 2595 18 Sous un systme de type Linux, ces tunnels sont gnralement raliss par des outils type stunnel. 19 cf. RFC 2554 et 2222 20 cf. RFC 2195 21 cf. RFC 2222 22 cf. RFC 2195, 1734 et 2595 pour lauthentication POP et RFC 1731, 2195 et 2595 pour IMAP
16 galement
Page 36 sur 46
dune de ces options dauthentication, il faudra veiller ce que les clients de messagerie aient la possibilit de se connecter au serveur en sauthentiant via le protocole utilis par le serveur de messagerie.
Page 37 sur 46
9
9.1
Maintenir le niveau de scurit : mesures gnrales

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

Exploitation des journaux
Une procdure doit expliciter les tches devant tre ralises en terme dexploitation des journaux. Chacune des tches unitaires doit tre dcrite et son droulement prcis. Cette procdure doit prciser, pour chaque systme et application : la priodicit de lanalyse des journaux et ses modalits (qui fait quoi, quand, etc. . .) ; o trouver les journaux analyser (serveur, station de travail etc. . .) ; quelles informations doivent tre recherches (accs successifs refuss, utilisation inhabituelle dun serveur, journaux des antivirus, des caches HTTP, FTP, etc. . .). noter quil existe des produits permettant une analyse semi-automatise de tels journaux simpliant grandement leur dpouillement ; Lusage de chiers journaux tournants23 est dun grand intrt pour la disponibilit du serveur. Il nest, en eet, pas ncessaire dans ce cas de grer la saturation du disque o sont stocks les journaux, disque ddi de prfrence, et les exceptions qui en dcoulent. Ce dispositif est par contre attaquable par saturation : les traces relles de lattaque pourront tre masques par des messages sans valeur. Il convient donc de sauvegarder les journaux avant de les r-craser.
10.2
Raliser une veille technologique sur les lments du rseau
Tous les composants techniques ont eu, parfois ont encore, et auront des failles. Il importe donc dtre lcoute dorganismes comme le CERTA qui alertent lors de lapparition de nouvelles failles24 : www.certa.ssi.gouv.fr ; www.cert.org et www.cert.org/current/current_activity.html.
10.3
Veille technologique
Les informations de scurit concernant les serveurs de messagerie utiliss seront consulter sur les sites des diteurs : ......
chier journal a toujours la mme taille et sauto-crase si ncessaire. serait souhaitable daviser pralablement le CERTA des choix de conguration qui ont t faits en terme de systme dexploitation, logiciels, etc., pour que le CERTA puisse cibler sa veille en fonction des produits les plus reprsentatifs.
24 Il
23 Le
Page 40 sur 46
11
11.1
11.1.1
Annexes
Points vrier gnraux
Mesures gnrales p. p. p. p. p. 12 12 13 13 18 O O O O O
Adapter le guide la PSSI applicable crire et mettre jour une politique de scurit Dvelopper et implmenter une dfense en profondeur Mettre en place des mcanismes de scurit physique tablir et tenir jour un relev de conguration des serveurs 11.1.2 Environnement rseau
Mettre en place une architecture scurise Installer des commutateurs Installer des outils de dtection dintrusion Rdiger la matrice des ux adapte larchitecture choisie pour le pare-feu Mettre en place la matrice des ux sur le pare-feu Choisir un protocole de tunnels chirants sur le rseau Mettre en place le protocole de tunnels chirant choisi 11.1.3 11.1.3.1 Systme dexploitation Installation du systme dexploitation
p. p. p. p. p. p. p.
23 16 16 25 25 26 26
O O O O O O O
Vrier la conguration du systme sous-jacent Choisir la version du serveur de messagerie installer Vrier les sources dinstallation Choisir le type dinstallation Installer le serveur de la messagerie sur une machine ddie Ninstaller que les services requis sur le serveur Utiliser un disque physique ddi ou au moins une partition dirente pour les botes aux lettres des utilisateurs Supprimer toute la documentation fournie sur le serveur 11.1.3.2 Conguration du systme dexploitation
p. p. p. p. p. p. p.
18 19 19 18 20 20 26
O O O O O O O O
p. 27
Employer des mots de passe forts Positionner correctement les permissions des chiers et ressources Fichiers de conguration des applicatifs et du systme Fichiers contenant des mots de passe chirs Fichiers contenant des cls de chirement Journaux du serveur Fichiers contenant les droits daccs aux dirents chiers Botes aux lettres des utilisateurs Limiter laccs du serveur de la messagerie un certain nombre de chiers Restreindre les droits du serveur de messagerie pour pouvoir crire des chiers journaux mais pas les lire Restriction des chiers temporaires un rpertoire spcique bien protg uniquement accessible par lutilisateur ayant cr ces chiers Grer les droits et permissions des utilisateurs correctement Installation du serveur dans une arborescence conne (pour les systmes de type Unix)
p. 20 p. p. p. p. p. p. 27 27 27 27 27 27
O O O O O O O O O O O
p. 27 p. 27 p. 27 p. 28
Page 41 sur 46
11.1.3.3
Antivirus p. p. p. p. p. 24 24 28 24 28 O O O O O
Choisir lemplacement du ou des antivirus de serveur Choisir le ou les antivirus de serveur Choisir les antivirus de client de messagerie Congurer le ou les antivirus de serveur Congurer les antivirus de client de messagerie 11.1.4 11.1.4.1 Postes des utilisateurs Installation des clients de messagerie
Sensibiliser les utilisateurs Mettre la dernire version stable du client de messagerie Mettre les derniers correctifs sur le client de messagerie Mettre les derniers correctifs sur le navigateur Internet (si le client de messagerie est dpendant du navigateur, tel Outlook Express) Figer la conguration des postes avant le dploiement des clients de messagerie 11.1.4.2 Conguration des clients de messagerie la visualisation automatique des messages louverture automatique des messages suivants lexcution automatique de contenu mot de passe de messagerie robuste et dirent des autres mots de
p. p. p. p.
28 29 29 29
O O O O O
p. 29
Dsactiver Dsactiver Dsactiver Choisir un passe 11.1.4.3
p. p. p. p.
29 29 29 29
O O O O
Programmes de scurisation des clients de messagerie p. p. p. p. 31 30 29 31 O O O O
Choisir un logiciel Dployer une IGC adapte Installer et congurer les postes utilisateurs Former les utilisateurs
11.1.5 11.1.5.1
Serveurs de messagerie Conguration du serveur p. p. p. et p. 32 32 32 34 33 O O O O O
Choisir un utilisateur pour lapplicatif avec des droits rduits Mettre en place une invite de commande non-valide pour cet utilisateur Supprimer les commandes inutiles sur le serveur (EXPN, VRFY, DEBUG, X. . .) Supprimer les traces permettant didentier le serveur via une connexion sur le port 25 Supprimer les traces permettant didentier le serveur via les informations laisses dans lentte des messages lectroniques 11.1.5.2 Extensions de scurit
p. 34
Mettre en place STARTTLS et SSL pour POP Mettre en place une IGC adapte Installer des certicats clients Installer des certicats serveurs Mettre en place un systme dauthentication du client
p. p. p. p. p.
36 36 36 36 36
O O O O O
Page 42 sur 46
11.2
11.2.1
Points vrier pour Microsoft Exchange 5.5

Avertissement
Cette liste de points vrier nest quun exemple dapplication de ce guide et ne saurait se substituer une tude complte et rchie de la scurit dun serveur de messagerie Exchange 5.5. Elle ne sadapte pas par exemple de nombreux cas particuliers. Cette liste ne doit donc pas tre applique strictement la lettre, mais pourrait tre une aide pour scuriser ce serveur. Les recommandations de scurit doivent bien videmment tre testes avant dtre dployes sur un rseau oprationnel. 11.2.2 11.2.2.1 Installation Pr-installation O O O O O O
Crer un compte pour Exchange Mettre en place un compte ddi cet usage Mettre en place un nom de compte non identiable Ne pas remplir la description du compte Mettre en place un mot de passe complexe Crer un groupe pour Exchange Mettre en place un groupe dirent des groupes dadministration NT Choisir plusieurs groupes Exchange pour rpartir les tches (installation de comptes, lecture des chiers journaux, . . .) 11.2.2.2 Installation
Utiliser un disque physique dirent pour les botes aux lettres Utiliser un disque physique dirent pour les chiers journaux Utiliser une partition dirente du systme dexploitation pour lapplicatif Mettre en place les derniers services packs et correctifs (rollup packages, hotxes) 11.2.2.3 Post-installation
O O O O
Mettre en place la permission contrle total sur le rpertoire principal de Exchange, les sous-rpertoires et les chiers pour les utilisateurs suivants : Crateur propritaire Administrateurs de domaine System Compte cr pour Exchange Groupe administrateur cr pour Exchange Supprimer laccs ce rpertoire, aux sous-rpertoires, et aux chiers pour les autres utilisateurs Modier les permissions associes au chier %systemroot%\SYSTEM32\mapisvc.inf pour permettre au groupe Utilisateurs authentis davoir la permission Modier
O O O O O O O
Page 43 sur 46
11.2.3 11.2.3.1
Administration des composants Exchange Annuaire O
Mettre en place des droits adapts pour laccs lannuaire LDAP au niveau du site : Cliquer sur lobjet Domaine , puis Conguration Ouvrir Conguration du service annuaire du site Aller sur longlet Attributs Positionner correctement les droits associs, en particulier les permissions pour les utilisateurs anonymes qui ne devraient pas avoir accs aux informations de lannuaire Paramtrer lenregistrement des diagnostics pour journaliser les vnements appropris : Slectionner le serveur dans lobjet Serveurs Cliquer sur Fichier, Proprits Cliquer sur longlet Enregistrement des diagnostics et slectionner le champ MSExchangeDS Positionner lenregistrement des diagnostics pour journaliser ce qui est intressant. Les options qui devraient tre positionnes au niveau maximum sont les suivantes : Scurit et Interface LDAP . Par la suite, lobservateur dvnements de Windows permet de visualiser les vnements enregistrs. 11.2.3.2 Banque dinformations
Activer le suivi des messages dans la conguration de la banque dinformations du site : Cliquer sur lobjet Domaine , puis Conguration Ouvrir Conguration de la banque dinformations du site Aller sur longlet Gnral Activer le suivi des messages Restreindre les droits des utilisateurs sur les rpertoires selon lusage fait des rpertoires publics (partage de messages lectroniques, de chiers, groupes de discussion, . . .) Cliquer sur lobjet Domaine , puis Conguration Ouvrir Conguration de la banque dinformations du site Aller sur longlet Cration dun dossier de haut niveau Positionner les utilisateurs autoriss selon lusage fait de ces rpertoires publics Paramtrer lenregistrement des diagnostics pour journaliser les vnements pour la banque dinformations prive Slectionner le serveur dans lobjet Serveurs , puis, lintrieur de cet objet, slectionner lobjet Banque dinformations prive Cliquer sur Fichier, Proprits Cliquer sur longlet Enregistrement des diagnostics et slectionner le champ MSExchangeIS , puis Priv Positionner lenregistrement des diagnostics pour journaliser ce qui est intressant. Les options qui devraient tre positionnes au niveau maximum sont les suivantes : ouvertures de sessions , contrle daccs , envoyer de la part de , envoyer en tant que , et tlcharger Paramtrer lenregistrement des diagnostics pour journaliser les vnements pour la banque dinformations publique : Slectionner le serveur dans lobjet Serveurs , puis, lintrieur de cet objet, slectionner lobjet Banque dinformations publique Cliquer sur Fichier, Proprits Cliquer sur longlet Enregistrement des diagnostics et slectionner le champ MSExchangeIS , puis Publique Positionner lenregistrement des diagnostics pour journaliser ce qui vous intresse. Les options qui devraient tre positionnes au niveau maximum sont les suivantes : ouvertures de sessions , contrle daccs , envoyer de la part de , envoyer en tant que , et tlcharger
Page 44 sur 46
11.2.3.3
Agent de transfert des messages O O
Mise en place du suivi des messages au niveau du site Cliquer sur lobjet Domaine , puis Conguration Ouvrir Conguration du MTA du site Aller sur longlet Gnral Activer le suivi des messages Paramtrer lenregistrement des diagnostics pour journaliser les vnements pour la banque dinformations publique : Slectionner le serveur dans lobjet Serveurs , puis, lintrieur de cet objet, slectionner lobjet Agent de transfert des messages Cliquer sur Fichier, Proprits Cliquer sur longlet Enregistrement des diagnostics Positionner lenregistrement des diagnostics pour journaliser ce qui vous intresse. Les options qui devraient tre positionnes au niveau maximum sont les suivantes : scurit et conguration 11.2.4 Congurer le service messagerie Internet (SMTP)
Limiter la taille des messages Cliquer sur lobjet Domaine , puis Conguration , puis Connexions Ouvrir Service messagerie Internet Slectionner longlet Gnral Positionner la taille des messages en fonction du nombre dutilisateurs et de la taille de vos disques Activer le suivi des messages Cliquer sur lobjet Domaine , puis Conguration , puis Connexions Ouvrir Service messagerie Internet Cliquer sur longlet Messagerie Internet Activer le suivi des messages Autoriser lutilisation de S/MIME et dsactiver les rponses automatiques Cliquer sur lobjet Domaine , puis Conguration , puis Connexions Ouvrir Service messagerie Internet Cliquer sur longlet Messagerie Internet Cocher les clients prennent en charge les signatures S/MIME si celles-ci sont utilises Cliquer sur Options avances Dsactiver les rponses dabsence du bureau, les rponses automatiques et lenvoi des noms complets Restreindre les accs des utilisateurs Cliquer sur lobjet Domaine , puis Conguration , puis Connexions Ouvrir Service messagerie Internet Cliquer sur longlet Restrictions de remise Restreindre les messages aux seuls utilisateurs autoriss Contrler les connexions SMTP Cliquer sur lobjet Domaine , puis Conguration , puis Connexions Ouvrir Service messagerie Internet Cliquer sur longlet Connexions Paramtrer loption Acceptation des connexions pour nautoriser que les communications authenties et chires Activer loption les clients peuvent dposer uniquement sils sont sur ce serveur (Ceci ncessite que les utilisateurs possdent dj une bote aux lettres sur le serveur pour envoyer des messages) Activer loption les clients peuvent dposer uniquement si le compte dauthentication correspondant ladresse du dpt
O O
Page 45 sur 46
11.2.5
POP/IMAP O
Activer un mcanisme de chirement des mots de passe en respectant les dirents types de clients de messagerie installs (par exemple le mcanisme NT Challenge/Response est un des plus scuriss mais ne marche quavec les clients de messagerie Microsoft, si lenvironnement est htrogne, un chirement de type SSL est conseill) Cliquer sur lobjet Domaine , puis Conguration , puis Protocoles Ouvrir Paramtres POP3/IMAP4 Cliquer sur longlet Authentication Slectionner un algorithme de chirement appropri 11.2.6 LDAP
Activer un mcanisme de chirement des mots de passe (cf. recommandations pour POP/IMAP partie 11.2.5) et interdire les connexions anonymes Cliquer sur lobjet Domaine , puis Conguration , puis Protocoles Ouvrir Paramtres LDAP Cliquer sur longlet Authentication Slectionner un algorithme de chirement appropri Cliquer sur longlet Anonyme Dcocher la case Permettre un accs anonyme (sauf si les utilisateurs veulent accder leurs messageries via un navigateur Web)
Page 46 sur 46

Guide Messagerie

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Guide Messagerie

Încărcat de

Drepturi de autor:

Formate disponibile

PREMIER MINISTRE

Secrtariat gnral de la dfense nationale

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

Direction centrale de la scurit des systmes dinformation

Recommandations de scurisation Messagerie

Recommandations de scurisation Messagerie

Nombre de pages du document : 46

Recommandations de scurisation Messagerie

Table des matires

Recommandations de scurisation Messagerie

Recommandations de scurisation Messagerie

Recommandations de scurisation Messagerie

Table des figures

Recommandations de scurisation Messagerie

qui sont destines ces recommandations

Prsentation des recommandations

Recommandations de scurisation Messagerie

Recommandations de scurisation Messagerie

Standards utiliss pour la messagerie lectronique

Recommandations de scurisation Messagerie

Principaux risques de la messagerie

Rception/Envoi messages falsis

Lecture de messages par de tierces personnes

Recommandations de scurisation Messagerie

Relais pour des messages extrieurs

Indisponibilit du serveur de messagerie

Rebond possible pour une attaque en interne

Recommandations de scurisation Messagerie

Politique gnrale de la scurit des systmes dinformation

Recommandations de scurisation Messagerie

Principes fondamentaux de la SSI

Recommandations de scurisation Messagerie

Ce quil faut prendre en compte prioritairement sur les lots techniques

Recommandations de scurisation Messagerie

Recommandations de scurisation Messagerie

appels sniers appels switchs 5 galement appels hubs

Recommandations de scurisation Messagerie

Principe du moindre privilge

Recommandations de scurisation Messagerie

Scuriser : mesures gnrales

Recommandations de scurisation Messagerie

Version du serveur de la messagerie installer

Recommandations de scurisation Messagerie

Emploi de mots de passe complexes

Recommandations de scurisation Messagerie

Recommandations de scurisation Messagerie

Recommandations de scurisation Messagerie

Scuriser : mesures spcifiques

Recommandations de scurisation Messagerie

Recommandations de scurisation Messagerie

Recommandations de scurisation Messagerie

Pare-feu FW-A FW-A FW-A FW-A FW-B FW-B

Protocole TCP TCP TCP TCP TCP TCP

Port dpart >1024 >1024 >1024 >1024 >1024 >1024

Port arrive 25 25 25 110 110 25

Fig. 2 Table des ux de pare-feu pour la messagerie

Installation de tunnels chirants

Scuriser le systme dexploitation

Recommandations de scurisation Messagerie

Recommandations de scurisation Messagerie

Scuriser les postes des utilisateurs

Recommandations de scurisation Messagerie

Conguration des programmes de messagerie

Recommandations de scurisation Messagerie