Guide Messagerie

8/3/2019 Guide Messagerie

1/46

P R E M I E R M I N I S T R E

Secrtariat gnral

de la dfensenationale

Issy les Moulineaux, le

n /SGDN/DCSSI/SDO/BAS

Direction centrale de lascurit des systmesdinformation

Recommandations de scurisation

Messagerie


2/46

Recommandations de scurisation Messagerie

Informations

Nombre de pages du document : 46

Evolution du document :

Version Rdaction Validation DCSSI Date

0.1 Cline Estieux Philippe Brandt

N /SGDN/DCSSI/SDO/BAS Page 2 sur 46


3/46


Table des matires

1 Introduction 7

1.1 Objectifs des recommandations . . . . . . . . . . . . . . . . . . . . . . . . 71.2 qui sont destines ces recommandations . . . . . . . . . . . . . . . . . 7

1.3 Structure de ce document . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4 Prsentation des recommandations . . . . . . . . . . . . . . . . . . . . . . 7

2 Avertissements 8

3 Pr-requis 9

3.1 Matriels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Connaissances ncessaires . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3 Standards utiliss pour la messagerie lectronique . . . . . . . . . . . . 9

3.3.1 Structure dun message lectronique . . . . . . . . . . . . . . . . . . . . . . 9

4 Principaux risques de la messagerie 10

4.1 Rception/Envoi de virii . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2 Rception/Envoi messages falsifis . . . . . . . . . . . . . . . . . . . . . . 104.3 Lecture de messages par de tierces personnes . . . . . . . . . . . . . . . 104.4 Relais pour des messages extrieurs . . . . . . . . . . . . . . . . . . . . . 114.5 Perte de messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.6 Indisponibilit du serveur de messagerie . . . . . . . . . . . . . . . . . . 114.7 Rebond possible pour une attaque en interne . . . . . . . . . . . . . . . 11

5 Politique gnrale de la scurit des systmes dinformation 12

6 Principes fondamentaux de la SSI 13

6.1 Dvelopper et implmenter une dfense en profondeur . . . . . . . . . . 136.1.1 La scurit des locaux et la sret de fonctionnement . . . . . . . . . . . . . 13

6.1.1.1 Ce quil faut prendre en compte prioritairement sur les lots techniques 146.1.2 La dfense au niveau du rseau . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.1.2.1 Utilisation de commutateurs . . . . . . . . . . . . . . . . . . . . . 166.1.2.2 Mise en place doutils de dtection dintrusion . . . . . . . . . . . 16

6.1.3 La dfense au niveau des htes . . . . . . . . . . . . . . . . . . . . . . . . . 166.1.4 La dfense au niveau des applications . . . . . . . . . . . . . . . . . . . . . 16

6.1.5 La dfense au niveau des donnes . . . . . . . . . . . . . . . . . . . . . . . . 166.2 Principe du moindre privilge . . . . . . . . . . . . . . . . . . . . . . . . . 17

7 Scuriser : mesures gnrales 18

7.1 Relev de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187.2 Pralables de linstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7.2.1 Vrification du systme sous-jacent . . . . . . . . . . . . . . . . . . . . . . . 187.2.2 Version du serveur de la messagerie installer . . . . . . . . . . . . . . . . . 197.2.3 Vrification des sources dinstallation . . . . . . . . . . . . . . . . . . . . . . 19

7.2.3.1 Mdia physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197.2.3.2 Installation dun applicatif tlcharg . . . . . . . . . . . . . . . . 19

7.2.3.3 Installation directe depuis un rseau externe . . . . . . . . . . . . 197.3 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20



4/46


7.4 Emploi de mots de passe complexes . . . . . . . . . . . . . . . . . . . . . 207.5 Administration du systme . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.5.1 Administration locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217.5.2 Administration distante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.5.2.1 Terminal Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 217.5.2.2 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227.5.2.3 Tlmaintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8 Scuriser : mesures spcifiques 23

8.1 Scuriser lenvironnement rseau . . . . . . . . . . . . . . . . . . . . . . . 238.1.1 Mise en place dune architecture scurise . . . . . . . . . . . . . . . . . . . 238.1.2 Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

8.1.2.1 Positionnement et fonctionnement de lantivirus . . . . . . . . . . 248.1.3 Adapter et contrler la configuration du pare-feu . . . . . . . . . . . . . . . 258.1.4 Installation de tunnels chiffrants . . . . . . . . . . . . . . . . . . . . . . . . 26

8.2 Scuriser le systme dexploitation . . . . . . . . . . . . . . . . . . . . . . 26

8.2.1 Installation du systme dexploitation . . . . . . . . . . . . . . . . . . . . . 268.2.1.1 Choix des serveurs de messagerie . . . . . . . . . . . . . . . . . . . 268.2.1.2 Disques et partitionnement du serveur de messagerie . . . . . . . . 268.2.1.3 Suppression de la documentation sur le serveur . . . . . . . . . . . 278.2.1.4 Configuration des journaux . . . . . . . . . . . . . . . . . . . . . . 27

8.2.2 Configuration du systme dexploitation . . . . . . . . . . . . . . . . . . . . 278.3 Scuriser les postes des utilisateurs . . . . . . . . . . . . . . . . . . . . . . 28

8.3.1 Sensibilisation des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . 288.3.1.1 Non-divulgation de message contenant des informations sensibles

sur Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288.3.1.2 Prserver la rputation dune entit . . . . . . . . . . . . . . . . . 288.3.1.3 Ne pas perturber la disponibilit du serveur de messagerie . . . . 28

8.3.1.4 Utiliser un programme de scurisation des messages lectroniques 288.3.2 Antivirus des clients de messagerie . . . . . . . . . . . . . . . . . . . . . . . 288.3.3 Configuration des programmes de messagerie . . . . . . . . . . . . . . . . . 298.3.4 Verrouillage de la configuration des postes . . . . . . . . . . . . . . . . . . . 298.3.5 Utilisation de mots de passe complexes . . . . . . . . . . . . . . . . . . . . . 298.3.6 Utilisation de programmes client de scurisation des messages lectroniques 30

8.3.6.1 Standards utiliss pour le chiffrement des messages lectroniques . 308.3.6.2 Choix dun programme de scurisation . . . . . . . . . . . . . . . 31

8.3.7 Systme daccs aux messages lectroniques via un navigateur Internet . . . 318.4 Scuriser les serveurs de la messagerie . . . . . . . . . . . . . . . . . . . . 32

8.4.1 Configuration des serveurs de messagerie . . . . . . . . . . . . . . . . . . . . 32

8.4.1.1 Excution du programme sous un utilisateur possdant des droitsrduits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328.4.1.2 Suppression des commandes inutiles sur le serveur de messagerie . 328.4.1.3 Suppression des traces permettant didentifier le serveur de messagerie 328.4.1.4 Mise en place de protocoles de scurisation adapts . . . . . . . . 35

9 Maintenir le niveau de scurit : mesures gnrales 38

9.1 Rgles dexploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389.1.1 Gestion des correctifs de scurit (serveurs et clients) . . . . . . . . . . . . . 389.1.2 Ralisation de fiches rflexes pour grer les alertes . . . . . . . . . . . . . . 389.1.3 Formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

9.1.4 Gestion des comptes et des mots de passe . . . . . . . . . . . . . . . . . . . 389.1.5 Serveur de secours et de test . . . . . . . . . . . . . . . . . . . . . . . . . . 399.1.6 Gestion des sauvegardes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39



5/46


9.1.7 Gestion des lments temporaires . . . . . . . . . . . . . . . . . . . . . . . . 399.2 Mise jour de la PSSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399.3 Audits de scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

10 Maintenir le niveau de scurit : mesures spcifiques 40

10.1 Exploitation des journaux . . . . . . . . . . . . . . . . . . . . . . . . . . . 4010.2 Raliser une veille technologique sur les lments du rseau . . . . . . 4010.3 Veille technologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

11 Annexes 41

11.1 Points vrifier gnraux . . . . . . . . . . . . . . . . . . . . . . . . . . . 4111.1.1 Mesures gnrales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4111.1.2 Environnement rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4111.1.3 Systme dexploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

11.1.3.1 Installation du systme dexploitation . . . . . . . . . . . . . . . . 41

11.1.3.2 Configuration du systme dexploitation . . . . . . . . . . . . . . . 4111.1.3.3 Antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

11.1.4 Postes des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4211.1.4.1 Installation des clients de messagerie . . . . . . . . . . . . . . . . . 4211.1.4.2 Configuration des clients de messagerie . . . . . . . . . . . . . . . 4211.1.4.3 Programmes de scurisation des clients de messagerie . . . . . . . 42

11.1.5 Serveurs de messagerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4211.1.5.1 Configuration du serveur . . . . . . . . . . . . . . . . . . . . . . . 4211.1.5.2 Extensions de scurit . . . . . . . . . . . . . . . . . . . . . . . . . 42

11.2 Points vrifier pour Microsoft Exchange 5.5 . . . . . . . . . . . . . . . 4311.2.1 Avertissement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4311.2.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

11.2.2.1 Pr-installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4311.2.2.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4311.2.2.3 Post-installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

11.2.3 Administration des composants Exchange . . . . . . . . . . . . . . . . . . . 4411.2.3.1 Annuaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4411.2.3.2 Banque dinformations . . . . . . . . . . . . . . . . . . . . . . . . 4411.2.3.3 Agent de transfert des messages . . . . . . . . . . . . . . . . . . . 45

11.2.4 Configurer le service messagerie Internet (SMTP) . . . . . . . . . . . . . . . 4511.2.5 POP/IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4611.2.6 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46



6/46


Table des figures

1 Exemple darchitecture scurise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Table des flux de pare-feu pour la messagerie . . . . . . . . . . . . . . . . . . . . . 263 Liste dextensions supportes par le serveur ESMTP domaine.exemple . . . . . . . 334 Informations rvles lors dune connexion un serveur de messagerie . . . . . . . 33

5 Informations rvles lors dune connexion un autre serveur de messagerie . . . . 336 Informations rvles dans lentte dun message lectronique . . . . . . . . . . . . 347 Informations sur larchitecture et les machines rvles dans lentte dun message

lectronique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35



7/46


1 Introduction

1.1 Objectifs des recommandations

Ce guide a pour vocation daider scuriser la messagerie laide de recommandations basessur ltat de lart.

1.2 qui sont destines ces recommandations

Ces recommandations sont destines principalement aux administrateurs, responsables de la s-curit des systmes dinformation et en gnral toute personne ou organisation voulant scuriserou vrifier la scurisation de la messagerie. En particulier ce guide nest pas un guide dadminis-tration 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 deserveurs ;

Partie 8 : recommandations spcifiques la scurisation de la messagerie ne mettre enoeuvre quune fois, linstallation du systme ou lors de la premire mise en application dece document ;

Partie 9 : recommandations gnrales sur les oprations mener pour conserver un bon niveaude scurisation dans le temps ;

Partie 10 : recommandations sur les oprations spcifiques la messagerie destines conser-ver 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 lavie 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 auxmesures spcifiques participant lobjectif final.



8/46


2 Avertissements

La responsabilit du choix et de la mise en oeuvre des recommandations proposes dans cedocument incombe au lecteur de ce guide. Il pourra sappuyer sur la politique de scurit du systmedinformation et sur les rsultats dune analyse des risques de la scurit des systmes dinformationpour dterminer les recommandations les plus pertinentes. Le lecteur devra galement raliser des

tests exhaustifs afin de vrifier ladquation de ces recommandations avec son contexte particulier.Vu la nature volutive des systmes dinformation et des menaces portant sur ceux-ci, ce docu-

ment prsente un savoir-faire un instant donn et a pour ambition dtre rgulirement amlioret complt.

Vos commentaires sont les bienvenus. Vous pouvez les adresser ladresse postale suivante :

Bureau Audits en SSISGDN/DCSSI/SDO/BAS51, boulevard de la Tour-Maubourg75700 Paris 07 SP



9/46


3 Pr-requis

3.1 Matriels

3.2 Connaissances ncessaires

Le lecteur devra tre familier avec la notion de rseau, et connatre les protocoles suivants :SMTP et POP (ou IMAP).

3.3 Standards utiliss pour la messagerie lectronique

3.3.1 Structure dun message lectronique

Le message lectronique se compose de deux parties distinctes spares par au moins une lignevide :

lentte;

le corps du message.

Lentte comporte nombre dinformations utiles lenvironnement de lexpditeur ainsi quele chemin suivi par le message : expditeur, destinataire, date, priorit, serveurs utiliss pour letransit, sujet du message, . . .

Le corps du message contient quant lui le contenu du message proprement parler.



10/46


4 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. Eneffet, la messagerie lectronique permet de vhiculer tous les types de fichiers, en particulier lesscripts et les fichiers excutables. Si ces programmes sont excuts sur la machine qui a reu lecourrier, un virus est susceptible dinfecter la machine.

Cependant si les administrateurs pensent frquemment se protger de la rception de viriipour ne pas contaminer le rseau interne, lmission de virii nest que peu souvent voque. Ilest pourtant vital de se protger galement contre lmission de virii. En effet lmission de viriipeut bien videmment contaminer les autres, ce qui ne devrait pas arriver, mais peut aussi nuiregravement limage de marque dune entit et engendrer un dni de service. Cest pourquoi lesdeux aspects de la protection virale (mission et rception doivent tre mis en uvre.

4.2 Rception/Envoi messages falsifis

Le protocole standard le plus utilis pour la messagerie lectronique est SMTP. Cependant ceprotocole ne prsente, dans sa fonction de base, i. e. la plus rpandue, aucune garantie contre lafalsification des messages lectroniques.

Il ny a par exemple aucun contrle effectu sur lexpditeur du message, et par consquentnimporte qui sur le mme rseau peut se faire passer pour quelquun dautre. Il ny a ainsi aucunegarantie quant lexpditeur du message avec un message envoy via SMTP. De la mme manire,le contenu mme des messages peut tre falsifi.

Il convient donc de se prmunir contre la rception et lenvoi de messages falsifis en utilisantles 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 reuspar ce biais sont transmis en clair sur le rseau, cest dire quils ne sont pas chiffrs.

Ainsi, toute personne coutant sur le rseau a la possibilit de voir le contenu du message1,identifier le contenu du message et galement lentte du message lectronique2. On peut se pr-munir de ce problme en envoyant une pice jointe chiffre, mais il faut garder lesprit quaveccette 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 lec-troniques sur un serveur. Il nest utilis quasiment que dans sa mise en oeuvre basique, cest--diresans scurit aucune. Pour rappel, son mode de fonctionnement est le suivant : un utilisateur sau-thentifie au serveur en envoyant son nom dutilisateur et son mot de passe, qui circulent en clairsur 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 lesmessages, au format dcrit prcdemment (cf. partie 3.3.1), circulant sur le rseau au momentde son coute. Mais il pourra galement, et cest une chose dont il conviendra de se prmunirfortement, rcuprer le nom et le mot de passe de lutilisateur cout pour prendre connaissanceultrieurement de ses messages son insu et galement essayer son mot de passe pour dautresapplications que la messagerie lectronique.

1voir exemple de message lectronique figure 72 titre de rappel, lentte comprend entre autres lexpditeur, le destinataire, et le sujet du message.



11/46


4.4 Relais pour des messages extrieurs

Une architecture scurise de rseau comprend gnralement au moins deux serveurs de messa-gerie : 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 messagesprovenant 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 sascurit devrait tre particulirement tudie. Il ne devrait avoir que deux fonctions : transmettredes messages en provenance ou destination du rseau local; il ne devrait donc en aucun caspouvoir servir de relais de messagerie entre deux rseaux extrieurs.

Si ctait le cas, le serveur faisant office de relais pourrait servir pour relayer des messages linsu de ladministrateur, tels lenvoi massif de publicit ( spam ) et les administrateurs de ceserveur pourraient tre poursuivis pour avoir permis la diffusion 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 despertes de messages. Ce risque doit tre pris en considration, car une perte de message lectroniqueest aujourdhui trs difficilement accepte par les utilisateurs.

Il faut galement penser la configuration du serveur antivirus sil existe, car si ce serveur estmal configur, il pourrait refuser et supprimer des messages contamins sans en informer lexpdi-teur 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 indisponiblependant une longue dure. Lindisponibilit peut tre due par exemple une saturation du serveurpar un grand nombre de messages envoys volontairement (attaque cible dun pirate), par un ouplusieurs messages envoys un nombre de destinataires lev. Lattaque peut galement provenirpar exemple de lenvoi de messages infects ou de messages rsultant de lenvoi dune chane desolidarit.

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 rseauinterne). Il est ainsi possible quil dispose de privilges supplmentaires par rapport un attaquantsitu 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 unrseau scuris qui naurait pu tre ralise autrement.



12/46


5 Politique gnrale de la scurit des systmes din-

formation

Un document, la politique de scurit dun SI (Systme dInformation) doit exister au sein delorganisme 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 dansle temps;

la liste des flux entrants/sortants vers/depuis le composant ;

la liste des services lancs au dmarrage ;

la liste des services audits et leurs fichiers ;

le suivi des mises jour des versions des logiciels utiliss ;

une copie des fichiers de configuration de tous les services et des fichiers de dmarrage ;

les mesures de scurit physique mises en place ;

la liste des correctifs et des modifications ralises sur le composant ; les oprations dexploitation mettre en uvre sur le composant.

Les recommandations nonces dans tout ce document devraient galement trouver leur placedans 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 laDCSSI, www.ssi.gouv.fr) pour plus dinformations sur ltablissement dune PSSI.

http://www.ssi.gouv.fr/http://www.ssi.gouv.fr/


13/46


6 Principes fondamentaux de la SSI

6.1 Dvelopper et implmenter une dfense en profondeur

Le principe de la dfense en profondeur est de multiplier les protections dune ressource (in-formation, composant, service. . .), tous les niveaux o il est possible dagir. Ainsi, un agresseur

devra passer outre plusieurs protections, de nature et de porte diffrentes, avant daccder laressource.

Ce principe doit tre appliqu tous les stades de la scurisation dune ressource quelle quensoit sa nature : une donne, une application, un systme, un rseau, voire mme le local hbergeantle 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 enuvre pour lexploitation de systmes dinformations sensibles, les principaux points techniquesncessaires seront ici abords sous langle de leur scurisation, sans entrer dans le dtail techniquede leur mise en uvre. En particulier, les diffrents lots techniques, au sens btimentaire (incendie,climatisation, . . .) possdent un grand nombre de contraintes techniques, rglementaires, lgalesainsi que des interrelations qui ne seront pas dtailles dans ce document.

Les rgles essentielles de scurit physique prendre en compte dans la conception ou lamna-gement de locaux, en vue de linstallation de systmes dinformation plus ou moins complexes etsensibles, recouvrent plusieurs lments de nature diffrente mais interdpendants.

Ces rgles appliquer sur tout ou partie de ces lments doivent sinscrire en amont de touteautres actions, dont lobjectif est de garantir en premire instance, laccs physique, lintgrit etla disponibilit dun systme dinformation et de ses donnes. Les situations gographiques, lesimplantations et les natures des constructions et des quipements dun site sont importantes auregard des risques naturels, de lenvironnement et des techniques mises en uvre. On sattacheradonc examiner les points suivants :

Lenvironnement :

La typologie des sols, magntisme naturel, nappes phratiques, rsistance aux effondre-ments, ...;

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 duPOS (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 (vibra-tions)), . . . ;

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 chargesrsultantes des prcipitations et jets dobjets, . . .), coulements des eaux uses et plu-viales, 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/extinctionincendie, . . .), implantation (usage ddi), type, nature, redondance (secours), renvoisdalarmes sur dfaillance.



14/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 oudirectement aux composants, ne doivent tre accessibles que par des personnels qualifis, internesou externes (maintenance), en rgime restrictif et contrls afin dabaisser les risques potentiels(malveillances, fausses manuvres, . . .).

Les agressions ou dfaillances sur des lments connexes au systme dinformation peuventconcourir son indisponibilit totale ou partielle. Pour cela, il y a ncessit de vrifier les pointssuivants :

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 decble). 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 ngocieravec le fournisseur un tirage de ligne, pour ce qui est hors site, empruntant un chemin physique

diffrent et venant dune sous station diffrente ;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 don-duleurs, . . .) renfermant des batteries et dont la composition est base dacide, doivent tre ddiset isols physiquement des matriels auxquels il sont raccords. Ces locaux seront munis duneventilation mcanique et amnags lectriquement en antidflagrant.

On vrifiera que les terres et masses (btiments, vrins supportant les faux planchers, matrielsinformatiques, PABX, . . .) sont conformes la rglementation (ex : terres informatiques < ou = 1Ohm, . . .). Dans la mme optique, on sassurera que les divers revtements de sols ou muraux sontanti-statiques.

On veillera ce que les divers ensembles lectriques primaires soient munis de parasurtenseursou parafoudre afin de limiter les risques krauniques sur les matriels pouvant se rvler sensiblesaux variations induites sur les diffrents 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 secourspar groupe lectrogne ddi ou partag peut tre envisag. Sa localisation est des plus importantes.En effet, on peut tre confront des problmes relatifs aux vibrations, ainsi quaux coups de blierds aux ondes stationnaires (longueurs des tubes dchappements des gaz) si ce dernier se trouveen sous-sol ou rez-de-chausse. Par ailleurs, il faudra sassurer de la prsence dun bac de rtentionde 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 de1/4 dheure afin de permettre une extinction propre des systmes. ce sujet, limplantation delonduleur (intermdiaire tampon, en cas de rupture dnergie, entre le fournisseur dnergie etle dmarrage du groupe lectrogne) ainsi que ses caractristiques intrinsques, seront tudis demanire 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 treau 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 deslments dont limportance est vitale pour la vie des matriels (serveurs, PABX, ..) par nature



15/46


fortement exothermiques. En effet, elles permettent de les rguler en temprature et hygromtrievitant ainsi les surchauffes et diminuant par voie de consquence le risque incendie. On prendrasoin pour les climatisations de relever le type, la nature, et la puissance de dissipation frigorifique.Lexistence dune redondance, afin dassurer une forte disponibilit, est fortement conseille.

Pour produire du froid, llment rfrigrant doit tre compress partir de compresseurs eux-mmes devant tre refroidis. Pour cela, des changeurs thermiques (arothermes) protgs en mal-veillance (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 sifflements) nivibratoire.

Les VMC (Ventilation Mcanique Centralis) seront judicieusement positionnes en particulierles prises daration (au regard des pollutions de lenvironnement et des vents dominants). Lesdiffrentes conductions de ventilation (gaines, faux planchers/plafonds..) et les reprises dair doiventtre vrifies au moins une fois lan et les filtres changs selon lenvironnement deux quatre foispar an.

Lensemble climatisation/ventilation se doit dtre asservi en arrt sur une dtection confirmedincendie, afin 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 n-cessaire que les locaux accueillants les matriels du systme dinformation ou y contribuant (ondu-leurs, cellules climatisation, nergie, . . .) soient protgs contre lincendie. cet gard, on choisirala nature (flammes, tempratures, fumes, . . .) et le type de la dtection (statique, diffrentiel,vlocimtrique, . . .) afin de lapproprier au risque le plus probable (une solution mixte peut treenvisage). Des solutions, manuelles (extincteurs appropris) ou automatiques (gaz non halogns,eau pulvrise, . . .), dextinction sont mettre en uvre pour complter et agir rapidement surlextinction dun incendie.

Les locaux ainsi que les gaines de ventilation, faux planchers/plafonds devront priodiquementfaire lobjet dun dpoussirage afin dviter ce vecteur complmentaire dincendie. Des alarmes

sonores et lumineuses locales avec renvoi vers un poste de surveillance devront accompagner lac-tivation de ces dtections. On relvera la prsence des dlments combustibles (revtement desparois, , . . .), lieux de stockage (papier, . . .), disposition relative des locaux, afin dagir sur ceslments pour abaisser le risque dincendie.

Enfin, 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 confidentialit le positionnement en sous-sols semble remporter la faveur, il estindispensable 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 desunits 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), ainsiquun second niveau (accs aux btiments), doivent tre installs sparment ou confondus selonla 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.



16/46


Des systmes anti-intrusion, actifs ou passifs, diffrents niveaux (enceinte, btiments, locauxsensibles...) doivent tre mis en uvre. Leur type et leur nature (grillage, barreaux, radars, infra-rouge...) doivent tre choisis dune manire cohrente au regard de lenvironnement.

Les alarmes, des contrles daccs et des dispositifs anti-intrusion, ainsi que leurs renvois intgrsou non dans une unit de gestion centralise, doivent imprativement tre complments par desconsignes et des procdures.

Ces mesures organisationnelles doivent tre cohrentes entre elles ainsi quau regard de leurenvironnement. Une redondance minimum et une autonomie sont indispensables afin de permettreune 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 naturesdiffrentes. On sattachera ce quelles ne soient pas gres par les mmes personnes et quelles nesoient pas techniquement regroupes.

6.1.2 La dfense au niveau du rseau

Il faut comprendre ici la dfense des flux circulant sur le rseau (limiter les flux autoriss, leschiffrer (contre lcoute et le piratage de session), limiter lutilisation de logiciels dcoute 3...),ainsi que des flux entrants ou sortants du primtre du rseau (mettre en place des moyens defiltrage, limiter les flux 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 com-mutateurs bien administrs. En effet si lon se passe de commutateurs 4 et que lon utilise desconcentrateurs 5, tout le trafic est diffus sur la totalit du rseau local, sans contrle possiblepar lexpditeur ou le destinataire. Ainsi, si quelquun coute le trafic local, il peut recevoir desinformations qui ne lui sont pas destines. Lutilisation de commutateurs est dautant plus recom-mande que la grande majorit des protocoles utiliss par les applications classiques (messagerielectronique, navigation Web, accs des fichiers distants. . .) ne sont pas chiffrs. Cependant, ilfaut noter que la protection apporte par un commutateur nest pas parfaite, car sujette desattaques au niveau du protocole de rsolution dadresse (ARP), et doit tre complte par dautresmesures dcoulant du principe de dfense en profondeur.

6.1.2.2 Mise en place doutils de dtection dintrusion

6.1.3 La dfense au niveau des htes

Elle consiste durcir le systme dexploitation dun composant, ainsi que ses relations avec lesautres composants du SI.

6.1.4 La dfense au niveau des applications

La scurisation dune application sappuie sur des mcanismes propres lapplication, maisaussi 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 fichiers, de messages lectroniques. . .). Le chiffrement et/ou des mesures de contrledaccs discrtionnaires permettent de protger les donnes stockes. De mme, des donnes trans-mises sous forme chiffre seront moins vulnrables en cas dinterception.

3galement appels sniffers 4galement appels switchs 5galement appels hubs



17/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.



18/46


7 Scuriser : mesures gnrales

7.1 Relev de configuration

Il est recommand dtablir et de tenir jour un relev de configuration des serveurs en dis-tinguant les diffrents types de serveurs et leur localisation dans larchitecture globale du systme

dinformation. Pour chacun de ces types, un document dcrira les choix de configuration 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 lidentification/authentification 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 desservices 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, telsque les Rollup Patches de Windows et les correctifs individuels, postrieurs aux RollupPatches, appels Hotfixes dans les environnements Windows ;

les rgles de contrle daccs aux ressources, et les droits positionns sur les cls de registre,rpertoires et fichiers ;

les rgles daudit et de journalisation ;

les mesures de chiffrement et dempreintes des fichiers critiques contenus sur les serveurs.

Les aspects lis lorganisation doivent galement tre dcrits. Ce document devra en particuliertre utilis pour toute nouvelle installation de serveurs de mme type. Un volet exploitation devraprciser les tches lies la scurit devant tre assures. On pourra pour cela sinspirer de lastructure du prsent document.

Lobjectif de ce document est multiple :

assurer une continuit de service en cas dabsence de ladministrateur charg de linstallationdu systme ;

faciliter la constitution dannexes techniques la PSSI ;

savoir sur quels composants assurer une veille technologique.

Ce relev de configuration papier du serveur contient des informations permettant daccderaux paramtrages du serveur, didentifier les versions du systme, des applications, des services,etc. Il doit donc tre identifi comme confidentiel et stock dans un endroit protg (local ferm cl par exemple).

Dune faon pratique, ce relev de configuration peut tre constitu en consignant les choixraliss lors de lapplication des diffrentes parties de ce document. Ce relev devra bien vidementfaire lobjet de mises jour aussi souvent que ncessaire, comme indiqu au paragraphe 9.1.1 page38.

7.2 Pralables de linstallation

7.2.1 Vrification du systme sous-jacent

Avant toute installation dun logiciel, il convient de vrifier que le systme, au sens large (systmedexploitation ou applicatif) a t install dans les mmes conditions que celles dcrites ultrieu-rement et quil a fait lobjet dune scurisation en se rfrant, par exemple, au guide DCSSI adhoc. 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 devraitpas tre install partir dune mise jour dune ancienne version.



19/46


7.2.2 Version du serveur de la messagerie installer

Il pourrait paratre naturel dinstaller la version franaise du serveur de la messagerie. Cepen-dant, un des principes de base de la scurisation est de maintenir le serveur de la messagerie audernier niveau de mise jour disponible. Or lexprience montre quil existe un dcalage de plu-sieurs 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 fil des ans. Il est donc recommanddinstaller le serveur de la messagerie dans sa version anglaise, plutt que sa version francise.

7.2.3 Vrification des sources dinstallation

Lors de linstallation dun lment logiciel (systme dexploitation ou applicatif) sur une ma-chine, 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 pr-cautions restent ncessaires. Il convient tout dabord de sassurer que le mdia propos nest pasune contrefaon mais quil mane bien directement de lditeur. Ensuite, il convient dexaminer lecontenu de ce mdia avec un anti-virus et ce quelque soit sa provenance. En effet, il se peut que despersonnes indlicates aient introduit des programmes malicieux (virus, chevaux de Troie, etc. . .)au cours du processus dlaboration du mdia.

Si les fichiers prsents sur le mdia ont fait lobjet dune signature numrique par lditeur, ilconvient de vrifier la validit de cette signature en utilisant la cl publique de lditeur et les outilsadquats. Ceci ne constitue cependant pas une preuve irrfutable de lexemption de contenu mali-cieux 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 lmetteursuivant de nombreux paramtres (dispositif cryptographique employ, mode de rcupration de lacl publique, soin apport par lditeur dans la gestion de ses cls prives, etc. . .). Il convient doncde bien comprendre les ventuels mcanismes cryptographiques mis en jeu avant de donner uneconfiance 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 deffec-tuer une analyse antivirale avant installation. Le problme supplmentaire pos ici rside dans lemode de rcupration des sources qui ne peut tre considr comme sr. Les mcanismes cryp-tographiques 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 parle 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 person-naliser le processus de vrification des sources avant installation si ce processus existe. Il convientdonc de sparer ces deux tches dautant plus que linstallation directe depuis Internet supposeque vous interconnectiez une machine que vous navez pas encore scuris ce qui serait une graveerreur.



20/46


7.3 Installation

Dans la mesure du possible, un serveur devrait tre ddi une seule fonction (par exemple, lamessagerie). Le principe de moindre privilge (cf. 6.2) doit guider toute installation. Il se traduitpar la limitation des fonctionnalits et des services installs au strict minimum requis par la fonc-tion 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 vrification pralablede leur bon fonctionnement sur le serveur de test afin dviter dventuels effets 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 parutionde nouveaux correctifs :

http://www.microsoft.com/TechNet/security/default.asp

Microsoft met la disposition du public un outil permettant de contrler la mise jour dusystme : hfnetchk.exe (Hotfix Network Checker). Cet outil excut en ligne de commande sur leserveur avec les droits administrateur contrle lensemble des mises jour appliques au systme

et aux applicatifs principaux de Windows, comme Internet Explorer, Outlook. . .. Il ncessite dedisposer dune base de signatures jour. Il est donc recommand de lancer tout dabord loutilsur une machine connecte Internet afin quil tlcharge la dernire base de signatures, puis detransfrer 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 effectue des tests complmentairessur le systme, comme la vrification 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), WindowsMediaPlayer (6.4 et postrieurs), et Internet Explorer (5.01 et postrieurs).

Ces deux outils permettent donc didentifier les mises jour qui nont pas t appliques pourensuite y remdier. MBSA permet en outre didentifier des vulnrabilits critiques du systme

dexploitation et des principales applications dites par Microsoft.Enfin, il est ncessaire de crer une disquette de dmarrage Windows, une disquette de rpara-

tion 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 contrelintrusion logique. Une bonne politique de choix et de gestion des mots de passe est donc le passageoblig pour scuriser une machine, voire un systme dinformation tout entier.

Afin dtre robuste aux attaques, un mot de passe doit tre complexe. Si lenvironnement danslequel il est utilis le permet, un mot de passe complexe doit avoir les proprits suivantes :

il se compose dun nombre suffisant 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;

chiffre;

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 systmeou sur un composant (compte administrateur, communaut SNMP avec droits en criture. . .),

on peut galement envisager lutilisation dun caractre ASCII non imprimable, obtenu en ap-puyant sur ALT et NB, o NB est un nombre compris entre 1 et 255 pour les environnementsWindows.

http://www.microsoft.com/TechNet/security/default.asphttp://www.microsoft.com/TechNet/security/default.asp


21/46


il nexiste dans aucune langue ni aucun dictionnaire ;

il est remis dans une enveloppe cachete lofficier de scurit qui la stocke dans un lieuadquat.

Lutilisation de tels mots de passe ne saurait tre efficace sans une complte acceptation par lesutilisateurs et les administrateurs des contraintes associes. En effet, 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 diffrentes. Cette pratiqueest particulirement dangereuse lorsque un mme mot de passe est utilis dans une appli-cation qui le transmet en clair sur le rseau (par exemple, la messagerie lectronique), o ilpeut tre facilement cout, et comme authentification dune ressource critique (par exemple,lauthentification systme).

puis de les former des comportements scuriss.

Ainsi, on peut aider les utilisateurs choisir un mot de passe complexe, en utilisant par exempledes aides mnmotechniques, expliquer la ncessit dun changement rgulier des mots de passe,

sensibiliser leur confidentialit (ne pas partager son mot de passe avec dautres utilisateurs, nepas communiquer son mot de passe sauf lofficier de scurit, etc. . .). In fine, les utilisateurs doiventpouvoir choisir des mots de passe mmorisables ou pouvant tre regnrs simplement chaqueutilisation. Dans le cas inverse, cette protection sera rendue inefficace par des comportementsinadapts (mots de passe marqus sur un post-it. . .). Enfin, une recrudesence dutilisateurs ayantbloqu leur compte ou ne se souvenant plus de leur mot de passe doit tre perue positivement,comme la manifestation de leffort quils font pour choisir des mots de passe complexes.

Il convient galement de garder lesprit les solutions techniques existantes pour se passer descontraintes inhrentes aux mots de passe : utilisation de systmes didentification et dauthentifica-tion forte (carte puce, cl USB, biomtrie, etc. . .), allis des dispositifs dits Single Sign On ,cest--dire permettant une identification et authentification forte unique pour toute une session(connexion une machine, accs des ressources locales ou distantes. . .).

7.5 Administration du systme

7.5.1 Administration locale

Il est recommand dadministrer un serveur localement, cest dire partir de sa console. Pources 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 autrecompte, avec des droits restreints.

7.5.2 Administration distante

Nanmoins, si une administration distante du serveur est requise, elle ne devrait pas pouvoirtre ralise depuis nimporte quel poste du rseau interne. Il est donc ncessaire de limiter cettefonctionnalit 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 scurisationde la station dadministration distance soit au moins quivalent celui du serveur (scuritphysique et logique). Sil est ncessaire de se connecter travers le rseau sur le serveur, il estprfrable dutiliser des outils dadministration chiffrs, fournis avec le systme ou tiers en raisondes 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 detels clients pour un grand nombre de systmes dexploitation, mme non Windows. Un administra-teur peut donc grer un serveur distance. Il est recommand dutiliser les fonctions de chiffrement



22/46


offertes par le composant Terminal Services (chiffrement lev ), afin de protger les donnescirculant sur le rseau. Si le service Terminal Services Web est utilis sur le serveur, on prendrasoin de modifier la page web par dfaut (/TSWeb/default.htm). Attention toutefois, car ce servicerequiert linstallation dun serveur web, ce qui augmente sensiblement la charge dadministrationet de scurisation du Terminal Services Web. Le seul moyen didentification et dauthentificationtant 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 treactive ou dfaut ne pas tre accessible depuis un rseau non sr. Si SNMP est active, lesnoms 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. Ilne devrait tre rebranch que lorsquune tlmaintenance est ncessaire, et aprs que la demande enait t faite par un intervenant identifi. Plusieurs mcanismes de scurisation du modem peuventtre mis en place :

modem acceptant exclusivement des mthodes dauthentifications fortes ;

modem assurant un rappel automatique dun numro pr-dfini (call-back) ;

modem acceptant le chiffrement.

Il est recommand dutiliser ces trois mcanismes conjointement.

Si tout ou partie de la tlmaintenance est ralise par des prestataires externes, il convientdimposer des rgles trs strictes de gestion des moyens didentification/authentification, et decontrle du personnel en charge de la prestation. En particulier, les mots de passe ne devraient pastre triviaux, ni partags entre les diffrents intervenants du prestataire et changs rgulirement,mme si cela peut tre lourd grer par le prestataire.



23/46


8 Scuriser : mesures spcifiques

8.1 Scuriser lenvironnement rseau

8.1.1 Mise en place dune architecture scurise

Lorsquune interconnexion du rseau interne avec Internet est prsente, une architecture scu-rise devrait tre mise en place afin de ne pas laisser de portes dentre un attaquant potentiel.Cette architecture devrait comporter deux serveurs de messagerie minimum pour limiter les risquesdattaques.

Si cette architecture est mise en place, le premier serveur est positionn au niveau de la zonedmilitarise (DMZ) et sert de relais pour envoyer ou recevoir les mails de lextrieur. Le deuximeserveur est positionn dans le rseau local et il est configur pour ne communiquer quavec leserveur de messagerie relais situ sur la DMZ. Un tel exemple darchitecture est insr dans ceguide. (figure 1).

Fig. 1 Exemple darchitecture scurise

Chaque serveur de messagerie devrait tre redond pour empcher une interruption de servicedun serveur de messagerie qui pourrait tre intentionnelle ou accidentelle. Il est galement re-command de scuriser les lments annexes du rseau ncessaires un bon fonctionnement desserveurs de messagerie, tels les serveurs de noms (DNS).



24/46


8.1.2 Antivirus

Un premier antivirus devrait tre mis en place pour contrler le flux global de messages lectro-niques (son positionnement exact sera discut dans la suite de ce document) et un second antivirussur les postes clients des utilisateurs. Le premier antivirus sera appel antivirus de serveur demessagerie dans ce document et le second antivirus des clients de messagerie .

Ces antivirus devront tre de technologie diffrente afin de rduire les risques ; en effet si un virusnest pas dtect par le premier antivirus, il le sera peut-tre par le second, ce qui augmentera leschances de dtection. Dautre part, les deux types dantivirus (flux et postes) sont complmentaires :par exemple lantivirus de serveur de messagerie ne peut pas analyser les messages chiffrs, mais lesantivirus des clients de messagerie le peuvent car pour lire les messages, il faut que les utilisateursles dchiffrent 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 lantivirusde serveur si les ressources en interne ne permettent pas une validation pralable. Il faut cependantbien garder lesprit que cette mise jour est une porte dentre pour une attaque potentielle. Ily a dj eu par le pass des attaques par ce biais. La solution de mise jour automatique ne doittre 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 lerecours des utilisateurs.

Il faut bien garder lesprit que lorsque lon a choisi de mettre en uvre une protectionantivirale, celle-ci est ncessaire pour les flux entrants et sortants comme il a dj t prcisau paragraphe 4.1.

Dautre part, il convient de bien se rappeler que cette protection nest pas totale et que lonnest jamais labri dun virus non encore reconnu par les antivirus ou encore cr spcifiquementpour attaquer une entit prcise. Cependant, la quasi-totalit des attaques virales sont repoussespar un antivirus bien configur 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 diffrents (cf. figure1) :

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 ser-veurs. 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 antivirusde serveur.

Cependant, la solution dinstaller lantivirus de serveur de messagerie sur le pare-feu ne devraitpas tre envisage. Lutilisation de service mandataire (proxy) ddi lanalyse antivirale ne feraitque 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 lesuivant : le serveur de messagerie coute sur le port 25 (SMTP), reoit les messages provenant delextrieur ou du serveur interne, analyse les messages, et sil ne trouve pas de virus, fait suivre lemessage vers son destinataire. Le message ne devrait pas tre dlivr sil y a un virus et pas simple-

ment tre nettoy puis envoy6

. Dautre part, on ne devra pas envoyer de message davertissement6En effet, 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.

http://www.certa.ssi.gouv.fr/http://www.certa.ssi.gouv.fr/site/CERTA-2000-INF-007http://www.certa.ssi.gouv.fr/site/CERTA-2001-ALE-012http://www.certa.ssi.gouv.fr/site/CERTA-2001-ALE-012http://www.certa.ssi.gouv.fr/site/CERTA-2000-INF-007http://www.certa.ssi.gouv.fr/


25/46


lmetteur du message pour linformer que celui-ci contenait un virus, car lmetteur du messagepeut avoir t falsifi.

Le serveur de relais intercepte ainsi les messages infects avant leur introduction sur le rseauinterne, cependant ce serveur est considrablement ralenti car chaque message est analys. Pour demeilleures performances, il peut tre envisag de faire tourner le serveur antivirus sur une machineddie dans la DMZ.

Pour rsumer, les avantages sont les suivants :

arrt du virus avant sa pntration dans le rseau interne ;

non-modification du serveur de messagerie interne.

Et les inconvnients sont les suivants :

modification du serveur relais de messagerie ;

ralentissement du serveur relais de messagerie ;

non-analyse via cet antivirus des messages circulant en interne (messages provenant du rseauinterne 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 internede messagerie. Le processus utilis est le mme que celui du serveur relais dcrit prcdemment et lesmmes prcautions devraient tre prises, savoir supprimer le message infect, avertir lexpditeuret envisager linstallation sur une machine ddie pour de meilleures performances. Cette solutionest dautant plus envisager que le serveur interne est souvent beaucoup plus charg que le serveurrelais.

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-modification du serveur relais de messagerie.

Et les inconvnients sont les suivants :

modification 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 configuration du pare-feu

Les pare-feux devraient bien videmment tre configurs en prenant garde de nautoriser que lesflux ncessaires et bien identifis. Il faudrait pour cela rdiger un tableau des flux passant traversles pare-feux et configurer les pare-feux en fonction de ces flux. En prenant lexemple de la figure 1,et en supposant que les serveurs de messagerie fonctionnent tous deux en SMTP et en POP pourle serveur interne, on obtient le tableau suivant pour les pare-feux, en supposant que celui-ci estde type stateful (cf. figure 2). Ici seuls les flux SMTP et POP ont t pris en compte. A celail faut galement ajouter les flux DNS, etc. et aussi les flux scuriss des protocoles prcdemmentcits si ceux-ci sont utiliss (SSMTP, POP3S, . . .)



26/46


Pare-feu Interface dpart Interface arrive Protocole Port dpart Port arriveFW-A 1 2 TCP >1024 25FW-A 2 1 TCP >1024 25FW-A 3 2 TCP >1024 25FW-A 3 2 TCP >1024 110FW-B 6 4 TCP >1024 110

FW-B 6 4 TCP >1024 25

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

8.1.4 Installation de tunnels chiffrants

Les protocoles de messagerie les plus utiliss i. e. SMTP, POP et IMAP ne sont absolument passcuriss dans leur version par dfaut. Ils laissent par exemple tout le trafic passer en clair entreles diffrentes machines. Ceci peut tre amlior en modifiant ces protocoles, mais cela ncessitegnralement des modifications substantielles des serveurs de messagerie (cf. partie 8.4.1.4).

Une alternative envisageable pourrait tre dinstaller des tunnels chiffrants entre toutes les

machines ou les diffrents serveurs. Le minimum serait, si lon choisit loption des tunnels chiffrants,de mettre en oeuvre ce tunnel entre les deux serveurs de messagerie : le serveur interne et le serveurrelais. Cependant, il faut savoir quainsi le trafic passe toujours en clair entre les machines client etle serveur. Quelquun coutant le trafic 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. Onpourrait par exemple installer des tunnels IPSec sur les diffrentes machines (A titre dexemple,ce protocole est disponible par dfaut dans Windows 2000 et ses versions postrieures ; si cettesolution 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 dcritesci-dessous qui sont indispensables pour une bonne scurisation du serveur mais ce ne sera passuffisant, car il faut galement configurer correctement le systme dexploitation prsent. Pour celail faudra consulter les recommandations de scurisation appropries dans les guides spcifiques auxsystmes dexploitation.

8.2.1 Installation du systme dexploitation

Un systme devrait tre scuris ds son installation et donc ne pas attendre quil soit dploypour le scuriser. Il est en effet beaucoup plus coteux et difficile de scuriser un serveur une foisquil a t configur 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 dex-ploitation associ. Cependant si cela est possible, le systme dexploitation devrait tre choisi pourtre le plus scuris possible. Il devrait donc tre le moins vulnrable aux diffrentes attaquespossibles, configurable le plus prcisment possible, tre capable de limiter laccs des utilisateursaux informations adquates, pouvoir restreindre le lancement des applications aux utilisateurs etrpertoires adapts, journaliser les vnements, etc. Les comptences du personnel ne devraient pastre oublies, il devra en effet 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 partitiondiffrente devrait tre install pour les fichiers contenant les botes aux lettres des utilisateurs.



27/46


Ce disque devrait tre diffrent du disque utilis pour le systme dexploitation et le systme duserveur de messagerie, ainsi en cas de saturation du disque par les messages des utilisateurs, lesdonnes systmes et applicatives ne seront pas corrompues.

Dautre part, il pourrait tre ncessaire dinstaller lapplication serveur de messagerie sur unepartition diffrente de la partition systme. En effet la partition systme, si elle est bien configure,a des droits restrictifs ne permettant pas lutilisation dun serveur de messagerie.

Et enfin, les fichiers journaux ncessiteront eux-aussi un disque physique diffrent ou au moinsune partition diffrente 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 avecce serveur pour pouvoir comprendre tous les paramtres de configuration de ce serveur et avoirrapidement accs ces informations.

Cette documentation est trs utile pour linstallation, mais une fois que le serveur est opra-tionnel, cette documentation ne devrait plus rester sur la machine en question. En effet si un piraterussit sintroduire sur le serveur, il aura a sa disposition toutes les informations utiles pour

reconfigurer le serveur directement.

8.2.1.4 Configuration des journaux

Les journaux devraient tre configurs pour rcuprer le plus grand nombre dinformations per-tinentes. 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 demessagerie devraient tre placs dans des rpertoires de taille suffisante. Des informations sur laconfiguration des journaux sont dcrites dans les guides spcifiques sur les systmes dexploitation.

Il faut cependant garder lesprit que nombre de serveurs de messagerie permettent, dans lesoptions de journalisation les plus compltes, de journaliser le contenu des messages lectroniquespassant par ces serveurs de messagerie. Or ce sont des donnes nominatives qui doivent faire lobjetdune dclaration la CNIL et qui doivent tre extrmement bien protges car les responsabilitssont grandes.

8.2.2 Configuration du systme dexploitation

Une fois que le systme dexploitation a t install de la faon la plus scurise possible, ilconviendrait de le configurer soigneusement afin de pallier aux risques potentiels. Si le systmedexploitation a t choisi comme dcrit prcdemment, il pourra permettre de positionner cor-rectement un grand nombre de paramtres : permissions des fichiers, limitation des utilisateurs,etc.

Les permissions devraient ainsi tre positionnes de manire trs scurise afin de permettre aux

utilisateurs et aux applications de naccder quaux donnes qui leur sont absolument ncessaires.En particulier il faudrait veiller aux permissions des fichiers suivants :

fichiers de configuration des applicatifs et du systme ;

fichiers contenant des mots de passe chiffrs ;

fichiers contenant des cls de chiffrement ;

journaux du serveur ;

fichiers contenant les droits daccs aux diffrents fichiers ;

botes aux lettres des utilisateurs.

Laccs du serveur de la messagerie devrait galement tre limit un certain nombre de fichiers :

le serveur de messagerie peut crire des fichiers journaux mais il ne devrait pas avoir les droitspour lire ces mmes fichiers ;

les fichiers temporaires devraient tre restreints un rpertoire spcifique bien protg quine sera accessible qu lutilisateur qui a cr ces fichiers.



28/46


Les droits et permissions des utilisateurs devraient eux aussi tre bien grs ainsi que ceux delapplicatif du serveur de messagerie. En particulier si lon est sous un systme de type Unix, oninstallera le serveur dans une arborescence confine7.

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

Sensibiliser les utilisateurs sur ce point devrait tre une action prioritaire. En effet, beaucoup nese rendent pas compte que leur message circule en clair sur Internet et quil est de ce fait susceptibledtre lu par nimporte qui. Il est essentiel de leur faire comprendre dune part que la messagerielectronique classique nest absolument pas scurise (pas dauthentification, pas de chiffrement,les mots de passe POP et IMAP peuvent passer en clair, . . .), et dautre part que sur Internet onne doit pas faire circuler dinformations sensibles.

8.3.1.2 Prserver la rputation dune entit

Lenvoi de messages provenant dune entit spcifique contenant des virii peut nuire sa rpu-tation. Cest galement le cas si les utilisateurs envoient des messages confidentiels via Internet.En sensibilisant les utilisateurs ce problme, on peut esprer rduire significativement 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 perturbet cela peut aller jusqu altrer sa disponibilit. Ceci peut galement arriver si les utilisateursenvoient rgulirement des messages trs volumineux, en particulier sils sont compresss et que lesserveurs 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 devraienttre sensibiliss au maniement de celui-ci pour apprendre lutiliser correctement. Ils devraient eneffet connatre les principes lmentaires mis en uvre (chiffrement, signature, authentification) etsurtout 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 configurs pour analyserles messages partant du poste et arrivant sur le poste des utilisateurs. Ces antivirus devraientgalement agir lorsque les utilisateurs ouvrent les messsages et pices jointes.

Dautre part, ces antivirus sont utiles pour la messagerie mais galement pour tous les fichierspotentiellement contamins prsents sur la machine des utilisateurs (rapatriement par disquettepar exemple, ce qui est un risque non ngligeable).

Ces antivirus devraient tre mis rgulirement jour par ladministrateur, sans interventiondes utilisateurs et ne devraient pas pouvoir tre dsactivs par les utilisateurs.

7galement appele chroot 8Le site http ://www.hoaxbuster.com peut tre un lien intressant pour la sensibilisation car il permet de vrifier

si un message est un canular ( hoax ) ou non. De plus amples informations sur ce sujet peuvent tre trouves danslavis du CERTA CERTA-2000-INF-005.

http://www.hoaxbuster.com/http://www.hoaxbuster.com/


29/46


8.3.3 Configuration des programmes de messagerie

Un des points les plus importants pour la scurisation des postes des utilisateurs devrait trede sassurer que les clients de messagerie utiliss sont bien installs dans leur version la plus stableet dote des derniers correctifs de scurit. En effet, la grande majorit de ces clients de messageriedisposent de nombreux correctifs supprimant les dernires vulnrabilits. Ces correctifs sont tl-

chargeables depuis les sites des clients de messagerie lectronique (cf. partie 10.3) en respectant lesprcautions lmentaires (cf. partie 7.2.3.2).

Dautre part, ces clients de messagerie lectronique ne sont pas toujours configurs par dfautavec la configuration la plus scurise. Il faudrait en effet sassurer que les points suivants ont bient configurs 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 seffectuer quen texte clair et non en HTML ;

lexcution automatique de contenu du message ne devrait pas tre active. En effet si lonreoit des pages HTML, avec du contenu actif tels des contrles ActiveX, des scripts JavaS-

cript ou tout autre code mobile, ce contenu ne devra pas sexcuter lorsque lon lit la pagecar les virus sont bien souvent propags par ce biais.

8.3.4 Verrouillage de la configuration des postes

La configuration dcrite dans la partie prcdente devrait tre effective sur tous les postes desutilisateurs, mais le problme est de sassurer que les utilisateurs conservent bien cette configurationsur leur machine et quils ne la changent pas. Cela devrait tre fait, car on constate souvent queles utilisateurs changent leurs paramtres pour plus de facilit et de convivialit et bien rarementpour plus de scurit.

Des utilitaires sont ainsi proposs par certains diteurs de clients de messagerie (par exempleOutlook Express et Netscape Messenger) pour figer la configuration des clients en une image bienparticulire que les utilisateurs ne pourront pas modifier. Cela est fait en amont : les administrateursconfigurent le client de messagerie et ventuellement le navigateur selon les options quils ontchoisies, ils dploient ensuite une version du client de messagerie modifie sur tous les postes etainsi les utilisateurs nont accs quaux options que leur administrateur rseau a bien voulu leurconfier. 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 passageoblig pour scuriser correctement un systme. Cest en effet gnralement un gros point faible du

systme car les utilisateurs ont du mal choisir un mot de passe complexe. Ils sont donc dautantplus 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 lemot de passe choisi devrait tre diffrent des autres mots de passe. En effet, comme le protocolePOP laisse passer les noms de compte et les mots de passe en clair, il serait trs facile pour unattaquant 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 paspermettre de rcuperer les mots de passe via le protocole POP standard, mais via des protocoles dercupration scurises (APOP, Kerberos/POP, TLS/SSL, . . .). Il est ainsi absolument ncessaireque les clients de messagerie supportent le protocole choisi.



30/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 messagerieusuels (SMTP, POP et IMAP sans extension de scurit), une solution de scurisation possible estdinstaller sur les postes des utilisateurs des programmes auxiliaires de chiffrement.

Cette solution permet ainsi dassurer des fonctions de scurit lmentaires (authentification,intgrit, confidentialit, . . .) pour la messagerie lectronique.

Les avantages de cette solution sont les suivants :

pas de modification des serveurs de messagerie existants (ni ceux en interne, ni les externespar lesquels passent des messages) ;

possibilit daffiner la solution selon les besoins (chiffrement et/ou signature) ;

scurisation des messages destination ou en provenance de correspondants extrieurs, devantpasser dans une zone non sre (Internet) sil existe le mme quipement cryptographique chezces correspondants et en interne;

confidentialit 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) ;

inefficacit des antivirus de serveurs analyser le contenu de ces messages.

8.3.6.1 Standards utiliss pour le chiffrement 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 dalgo-rithmes 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 clpublique quil peut donner nimporte qui.

La cl publique du destinataire est utilise pour envoyer des informations chiffres que seul ledestinataire pourra dchiffrer en utilisant sa cl prive. La cl prive de lexpditeur sert envoyerdes informations dont lauthenticit sera vrifie avec la cl publique de lexpditeur, connue detous.

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 (oupartage) sont galement utiliss dans le processus de scurisation des messages lectroniques, pourdes raisons de rapidit de traitement essentiellement. Typiquement, le processus de chiffrement estle suivant :

lexpditeur gnre une cl de session symtrique alatoire ;

lexpditeur chiffre le message en utilisant cette cl alatoire avec un algorithme cl sym-trique;

lexpditeur chiffre la cl de session avec la cl publique du destinataire du message ;

lexpditeur envoie son message chiffr et la cl de session chiffre au destinataire ;

le destinataire dchiffre la cl de session avec sa cl prive et ensuite son message avec la clde session.

On peut ainsi tre quasiment assur que seul le destinataire peut dchiffrer le message. En ralit,le nombre de cls est limit et donc il existe une probabilit quune autre personne dtienne lamme cl, et puisse dchiffrer le message. Cependant cette probabilit est extrmement faible.



31/46


8.3.6.1.2 Non-chiffrement des enttes

Il faut savoir que les programmes utilisateur de scurisation de la messagerie lectronique netraitent que le corps du message9, et jamais lentte. Ainsi si on envoie un message chiffr avec unsujet 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 destina-

taire ainsi que tout champ de lentte) peuvent tre sensibles. Lors de lenvoi dun message, uneprcaution lmentaire serait de sassurer quaucune information sensible ne soit contenue danslentte du message.10

8.3.6.1.3 Usages multiples

Ces programmes se prtent diverses utilisations : lauthentification, le chiffrement, lintgritet la non-rpudiation et on peut distinguer deux types de prestation offerte par ces programmes :la signature lectronique et le chiffrement. Pour la signature lectronique, le message lectroniqueenvoy est toujours transmis en clair, mais un condensat est envoy en mme temps que le messagelectronique au destinataire : cest la signature lectronique. Cette signature est cense11 garantirplusieurs choses : que lmetteur du message est bien celui qui a sign le message lectronique

(authentification), que le contenu du message na pas t falsifi (intgrit), et que lmetteur dumessage est bien le seul avoir pu lm

Date post:	06-Apr-2018
Category:	Documents
Upload:	kalil-ibrahim-macky
View:	233 times
Download:	0 times

Guide Messagerie

Documents