Amélioration et Sécurisation du réseau informatique

Entreprise : Panhard General Défense 2 rue Panhard et Levassor 91630 Marolles en Hurepoix

Auteur : Mr. HEZARD Roland Responsable entreprise : Mr. BEGUET Olivier Responsable enseignant : Mr. NAZIM Agoulmine

Amélioration et Sécurisation du réseau informatique

I

� Mise en place d’un accès à la messagerie depuis internet � Mise en place d’un serveur de mises à jour Microsoft � Mise en place d’une solution anti-spam � Mise en place d’un accès wifi pour les différents bâtiments de la société.

IUP Institut Universitaire Professionnalisé d'Evry MASTER 2 GEII Promotion 2007-2008

1 Panhard General Défense


PAGE de GARDE



Résumé

Pendant six mois, de février à juillet 2008, j’ai effectué mon stage de fin d’études de Master Génie Electrique et Informatique Industrielle au sein de l’entreprise PANHARD General Défense. Ce stage s’est déroulé au siège de la société à Marolles en Hurepoix (91).

Mon activité au sein de la société se résume ainsi :

� Evolution du parc informatique � Mise en place de serveurs � Maintenance Serveur � Mise en place de procédures � Formation du personnel

Mon stage s’articule sur plusieurs projets qui contribuent à l’amélioration et la sécurisation du réseau :

� Mise en place d’un accès à la messagerie depuis internet � Mise en place d’un serveur de mises à jour Microsoft � Mise en place d’une solution anti-spam � Mise en place d’un accès wifi pour les différents bâtiments de la société.

Pour mener à bien ces différents projets, plusieurs étapes ont été nécessaires pour chacun d’entre eux : une phase d’avant projets où ces derniers ont été étudiés, planifiés et préparés, une phase de réalisation et campagne d’essais, et pour terminer, la validation.

Mots-clés : Sécurité, Réseau, administration, relationnel.



Remerciements

Si la rédaction de ce présent rapport a pu être menée à son terme, c’est grâce à la

contribution de plusieurs personnes. Je tiens à remercier le Responsable Informatique de Panhard General Défense qui fut

mon tuteur de stage, Monsieur BEGUET Olivier. Il m’a permis de réaliser ces projets intéressants et je le remercie de la confiance qu’il m’a témoignée. Je remercie également le Directeur Informatique Monsieur DUCLOS Gérard ainsi que le Directeur des Ressources Humaines, Monsieur BRELLMAN Aymeric pour m’avoir accueilli au sein de la société.

Par ailleurs, j’adresse ma reconnaissance aux membres du service informatique,

Messieurs SAUCOURT Jean-Claude, GUE Daniel, SENG Xavier, LEDEBT Dominique et Madame ROCHER Emmanuelle pour leur professionnalisme, leur disponibilité et la mutualisation des compétences dont j’ai pu bénéficier tout au long de cette période de stage.

Pour terminer je tiens à remercier mes parents et mes amis qui m’ont soutenu et aidé

tout au long de mon stage.



Table des matières

Résumé ............................................ ................................................................................... 2 Remerciements ..................................... ............................................................................. 3 Table des matières ................................ ............................................................................ 4 Glossaire ......................................... ................................................................................... 6 Liste des illustrations ........................... ............................................................................. 9 Liste des annexes ................................. ........................................................................... 10 Introduction ...................................... ................................................................................ 11 Présentation de l’entreprise ...................... ...................................................................... 12

1. Historique de l’entreprise ........................................................................................ 12 2. Panhard aujourd’hui ............................................................................................... 12 3. Organigramme de PANHARD General Défense .................................................... 16 4. Organigramme du service Système d’information .................................................. 16

Présentation du travail demandé ................... ................................................................ 18 5. Contexte ................................................................................................................. 18 6. Objectifs ................................................................................................................. 18 7. Présentation du réseau .......................................................................................... 20 8. Impact des projets .................................................................................................. 21

1.1 Accès à la messagerie de l’entreprise via internet ....................................... 21 1.2 Serveur de centralisation des mises à jour Microsoft ................................... 23 1.3 Solution anti –spam ..................................................................................... 25

Organisation du travail effectué .................. ................................................................... 27 9. Méthodologie .......................................................................................................... 27 10. Responsabilités ...................................................................................................... 27 11. Solutions retenues .................................................................................................. 28

1.4 Reverse Proxy ............................................................................................. 28 1.5 anti-SPAM ................................................................................................... 32 1.6 Serveur de centralisation des mises à jour .................................................. 34

12. Contraintes ............................................................................................................. 35 1.7 ISA server .................................................................................................... 35 1.8 Serveur WSUS ............................................................................................ 35 1.9 IMF Anti-SPAM ............................................................................................ 35

Réalisation ....................................... ................................................................................. 36 13. ISA server ............................................................................................................... 36

1.10 Fonctionnement ........................................................................................... 36 1.11 Architecture du serveur ISA ......................................................................... 38 1.12 Interface du serveur ISA .............................................................................. 39 1.13 Pré-requis pour le déploiement .................................................................... 39 1.14 Création des certificats ................................................................................ 42 1.15 Configuration du serveur Exchange ............................................................. 44 1.16 Configuration du contrôleur de domaine ...................................................... 46 1.17 Configuration du serveur ISA ....................................................................... 46 1.18 Tests Réalisés ............................................................................................. 48 1.19 Problèmes rencontrés .................................................................................. 54

14. Serveur WSUS ....................................................................................................... 57 1.20 Principe de fonctionnement ......................................................................... 57 1.21 Interface ....................................................................................................... 57 1.22 Configuration ............................................................................................... 58 1.23 Tests ............................................................................................................ 59 1.24 Problèmes rencontrés .................................................................................. 59



15. IMF Exchange ........................................................................................................ 61 1.25 Principe de fonctionnement ......................................................................... 61 1.26 Configuration ............................................................................................... 62 1.27 Tests ............................................................................................................ 62 1.28 Problèmes rencontrés .................................................................................. 63

Conclusion technique et perspectives .............. ............................................................ 64 Conclusion ........................................ ............................................................................... 66 ANNEXES ......................................................................................................................... 67



Glossaire

SPAM : Ce terme anglophone désigne l'action d'envoyer des spams. De manière plus globale, le spamming peut être défini comme l'action d'exposer volontairement un grand nombre de personnes à un message indésirable en utilisant abusivement un moyen de communication licite. SPYWARE : (Spy Software) Les programmes de sypware sont de petits programmes informatiques qui visent à épier tout ce que vous faites sur votre ordinateur ou sur l'Internet. MALWARE : (Malicious Software) Les malwares correspondent aux programmes de type virus, vers ou chevaux de Troie développés dans le but de nuire au fonctionnement normal d'un système et de porter atteinte à ses utilisateurs. Cheval de Troie : Les chevaux de Troie ne sont pas des virus au sens strict. Ils ne peuvent pas se propager de façon autonome, mais sont généralement envoyés en même temps qu'un programme – souvent gratuit – ou un fichier, et ils se nichent à votre insu sur votre ordinateur. Une fois qu'ils sont sur votre ordinateur, ils peuvent détruire des fichiers. Les chevaux de Troie sont souvent écrits par des individus qui veulent ainsi avoir accès à votre PC via l'Internet par le biais d'une porte dérobée (backdoor). DoS : (Denial of Service) l'attaque qui vise à rendre une application informatique incapable de répondre aux requêtes de ses utilisateurs. DDos : (Distributed Denial of Service) Utilisation de zombies sur différentes machines pour provoquer un déni de service (DoS). Wifi : (WIreless Fidelity) Réseau local de type Ethernet à accès sans fil. Contrôleur de domaine : Désigne le responsable d'un réseau NT. Ce serveur central est en charge notamment des contrôles d'accès (Active Directory). Active Directory : Active Directory est un service d'annuaire proposé par Microsoft. Il a pour objectif de fournir des services d’authentification et d’identification. GPO : (Group Policy Objects) Les G.P.O sont des objets Active Directory qui définissent les droits des utilisateurs. Ce sont des stratégies de groupes. Outlook : Client de messagerie Pare-feu : Il filtre les flux d'informations entre un réseau interne et externe. Son objectif principal est de neutraliser les tentatives d’intrusions. Exchange : Serveur de messagerie Microsoft. LAN : (Local Area Network) Réseau local connectant des ordinateurs au sein d'une même entreprise.



WAN : (Wide Area Network). Réseau qui communique sur une longue distance, comme à l’échelle d’une ville ou à travers le monde DMZ : (Demilitarized Zone). Sous-réseau isolé par un pare-feu. Il se situe entre le LAN et internet. Proxy : Serveur faisant fonction d'intermédiaire entre les ordinateurs des particuliers ou d'un réseau local et Internet. Il filtre les connexions d’un réseau local vers internet. ReverseProxy : Comme son nom l’indique, sa fonction consiste à faire l’inverse du proxy, c'est-à-dire qu’il sert d’intermédiaire entre internet et le réseau local. Il relaye la requête d’un client (internet) vers un serveur interne (LAN). RPC : (Remote Procedure Call) Protocole permettant à un programme d’appeler des procédures se trouvant sur une machine distante, en interrogeant un serveur d’application. HTTP : (HyperText Transfer Protocol). Protocole standard de transmission des pages web sur internet. OWA : (Outlook Web Access) Webmail fournit par le serveur de messagerie Exchange. Webmail : Il s'agit d'un service permettant d'accéder à sa boite aux lettres depuis n'importe où, en utilisant un navigateur web pour se connecter à un serveur web offrant ce service. OSI : (Open System Interconnection) Norme d'échange de données entre ordinateurs ISA : (Internet Security and Acceleration Server). Application unifiant un proxy/reverse proxy, un pare-feu, et un VPN. Il permet d’effectuer un filtrage applicatif (web, ftp, smtp,…). MAC : (Medium Access Control) est un identifiant attribué à chaque carte réseau par le fabriquant. Sous-couche de la couche liaison de données. La couche MAC implémente le protocole qui contrôle l'accès au réseau. IP : (Internet Protocol). Elle désigne comme son nom l'indique le protocole de communication réseau utilisé sur Internet. Chaque ordinateur est muni d'une adresse IP, qui identifie de manière unique cette machine et son utilisateur au niveau mondial. IP publique : Elle est affectée par des organismes régionaux (dont un pour l'Europe) et sont donc des IPs accessibles directement accessible sur le net. LDAP : (Lightweight Directory Access Protocol). Protocole pour la gestion des services d'annuaire électronique Mise en cache Web : Permet d’alléger l’utilisation des ressources et de fournir un accès rapide aux donnnées. VPN : (Virtual Private Network) Réseau d'ordinateurs distants géographiquement, mais reliés virtuellement par des liaisons autres que celles dont disposent une entreprise.



Sharepoint : Windows SharePoint est un moteur de création de sites Web qui permet le partage des informations et le travail en équipe sur des documents. IMF : (Intelligent Message Filter) IMF est un filtre permettant de filtrer des messages et de les définir en tant qu’indésirables en se basant sur des probabilités. DNS : (Domain Name Server) C'est un serveur qui permet de convertir un nom de domaine en IP. Pr exemple, machine.domaine.com devient 88.188.188.12. FQDN : (Fully qualified Domain Name - Nom de domaine pleinement qualifié) Sur Internet, il s'agit de l'adresse complète d'une machine incluant son nom d'hôte et son nom de domaine. Par exemple, machine.domaine.com. Passerelle : dispositif permettant de relier deux réseaux informatiques d'autorités différentes (exemple : proxy, pare-feu …) Liste blanche : (whitelist) Liste d'émetteurs desquels vous acceptez toute correspondance. Veille technologique : Ensemble de techniques visant à organiser de façon systématique la collecte d’informations technologiques, l’analyse, la diffusion et l’exploitation de ces informations utiles à la croissance et au développement de l’entreprise.



Liste des illustrations

Fig.1 Chiffre d’affaire de Panhard General Défense p.14 Fig.2 Situation géographique de Panhard General Défense p.14 Fig.3 Présence internationale de Panhard General Défense p.15 Fig.4 Organigramme de l’organisation de Panhard General Défense p.17 Fig.5 Organigramme du service Amélioration de la performance p.18 Fig.6 Architecture générale du réseau informatique Panhard p.21 Fig.7 Configuration initiale de l’accès à la messagerie p.22 Fig.8 Nouvelle configuration de l’accès à la messagerie p.23 Fig.9 Configuration initiale du déploiement des mises à jour p.24 Fig.10 Nouvelle configuration du déploiement des mises à jour p.25 Fig.11 Coût du spam sans filtrage p.26 Fig.12 Coût du spam avec filtrage p.27 Fig.13 Modèle OSI p.30 Fig.14 Filtrage applicatif p.31 Fig.15 Avantage d’une DMZ p.32 Fig.16 Intégration du serveur ISA server 2006 p.37 Fig.17 Encapsulation http sur SSL/TLS p.38 Fig.18 Encapsulation LDAP sur SSL/TLS p.39 Fig.19 Architecture ISA server p.39 Fig.20 Interface ISA server p.40 Fig.21 Redirection du DNS public p.41 Fig.22 Couche SSL p.42 Fig.23 Certificat « mailhost.panhard.fr » p.44 Fig.24 Certificat « vsmdc.panhard.fr » p.44 Fig.25 Gestionnaire de site web IIS p.45 Fig.26 Configuration SSL IIS p.45 Fig.27 Forçage du SSL et cryptage à 128bits p.46 Fig.28 Option Authentification de base p.46 Fig.29 Vérificateur de connexion LDAPS p.47 Fig.30 Modèle réseau CARTE UNIQUE p.47 Fig.31 Résultat de l’analyse de trames pour les tests internes p.49 Fig.32 Validation de l’accès RPC over HTTPS p.50 Fig.33 Schéma de test avec ISA server 2006 en interne p.50 Fig.34 Analyse du trafic avec ISA en interne p.51 Fig.35 Schéma de test avec ISA server 2006 en DMZ p.53 Fig.36 Analyse du trafic avec ISA en DMZ p.54 Fig.37 Faille de niveau moyen du certificat p.56 Fig.38 Résultat de l’analyse du certificat après modification p.56 Fig.39 WSUS mode simple p.58 Fig.40 Interface de l’application WSUS p.58 Fig.41 Diagramme Filtre IMF p.62 Fig.42 Configuration du Niveau SCL p.63 Fig.43 Affichage SCL IMF companion p.63 Fig.44 Console de performance IMF p.64 Tableau.1 Impact d’un accès à la messagerie via internet p.23 Tableau.2 Comparatif des configurations de déploiement des mises à jour p.25 Tableau.3 Temps nécessaire pour violer un cryptage SSL p.42

10Panhard General Défense


Liste des annexes

Annexe 1 : Planning ref p.28 Annexe 2 : Notice d’accès OWA ref p.37- ref p.55 Annexe 3 : Accès au serveur de messagerie via Outlook ref p.37 Annexe 4 : Structure d’un certificat x509 ref p.42 Annexe 5 : Création d’un certificat auto-signé ref p.43 Annexe 6 : Configuration OWA ref p.37- ref p.46 Annexe 7 : Configuration du serveur ISA ref p.48 Annexe 8 : Configuration du client Outlook ref p.49 Annexe 9 : Rapport ISA server ref p.55 Annexe 10 : Création d’une règle GPO ref p.58 Annexe 11 : Rapport de mises à jour WSUS ref p.60 Annexe 12 : Rapport d’installation des mises à jour sur poste ref p.60 Annexe 13 : Procédure d’installation et d’administration d’IMF ref p.64



Introduction

Aujourd’hui, une bonne maîtrise des services informatiques passe par une gestion centralisée et optimisée des biens et processus associés. En effet, des causes "extérieures" (virus, externalisation, …) à l'entreprise viennent souvent accroître la complexité de gestion et d'administration. Ce qui fait la qualité d’un bon réseau d’entreprise, c’est sa disponibilité (qualité de service), et sa sécurité. Il est primordial pour le bon fonctionnement d’une société et pour améliorer sa productivité, que les serveurs d’un réseau répondent au plus vite aux requêtes et que les risques d’infiltrations, d’attaques virales soient minimiser. Par ailleurs, de nos jours, les utilisateurs deviennent de plus en plus mobiles et le réseau entreprise se voit de plus en plus ouvrir l’accès à leur serveur. Cette nouvelle forme d’utilisation amène à se poser des questions sur la sécurisation de ces accès. Grâce à l’évolution des systèmes de sécurité internet, la possibilité de déployer sans risque les serveurs d’une entreprise, est devenue réalisable tout en minimisant le coût d’une telle opération. Mon stage prend pleinement place dans ce contexte puisqu’il a pour objectif d’améliorer l’utilisation de la bande passante, de minimiser l’infiltration de SPAM, de mettre en place du wifi et de déployer la messagerie de l’entreprise via internet. Ces thèmes prennent donc une place importante dans l’entreprise et je vais, tout d’abord, présenter l’entreprise Panhard General Défense pour ensuite expliquer le contexte. Je démontrerai l’impact des différents projets, puis je décrirai la méthodologie employée pour les mener à bon terme. Je ferai ensuite une présentation des solutions choisies et du travail effectué. Je finaliserai ce rapport par une conclusion technique et générale présentant le résultat du travail effectué ainsi que l’importance que celui-ci a pu avoir pour mes perspectives professionnelles.



Présentation de l’entreprise

1. Historique de l’entreprise

Panhard , de son nom complet Panhard et Levassor , est un constructeur automobile français. L’entreprise fut fondée en 1891 par deux associés, Louis François René Panhard et Emile Levassor, dans le but de construire des automobiles à moteur à explosion. En 1903, la mort d'Émile Levassor, entraîna l’entreprise Panhard-Levassor à se concentrer sur la production de camions et de voitures de luxe. Avant la 1ère guerre mondiale, Panhard fut le premier constructeur français. Dès 1904, l’armée française recevait ses premières automitrailleuses Panhard-Genty. Dès lors, la marque Panhard fut étroitement liée à toutes les opérations réalisées par l’armée de terre. La robustesse et la performance des Panhard furent de précieux atouts, surtout dans les périodes difficiles de l’armée française. Les conditions économiques de l'après-guerre contraignirent la firme Panhard à produire des voitures plus abordables. Mais le manque d'une gamme suffisamment étoffée et les moyens financiers limités, handicaperont la firme : la branche civile des voitures particulières fut absorbée par la firme Citroën en 1965. Celle qui aurait pu sauver sa concurrente fut sa destructrice par l’arrêt de la production automobile. Désormais, dès 1907, Panhard, se limitait à la construction des véhicules militaires blindés dans son usine de Paris. Après l'échec de Fiat, c'est à Peugeot que Michelin vendit Citroën et Panhard en 1974. Début 2005, PSA Peugeot Citroën vend la société à SNAA Auverland fondée par François Servanin mais conserve le nom "Panhard" pour une éventuelle utilisation civile future. Le nouvel ensemble prend le nom de "Panhard General Défense" sous la direction de monsieur Christian Mons. Cette fusion a permis d’ouvrir de nouvelles perspectives pour la société grâce à une gamme élargie de produits complémentaires.

2. Panhard aujourd’hui

Nom : Panhard General Défense Statut Juridique : SA à conseil d’administration Capital : 1 024 000 € CA 2007 : 78 millions € SIRET : 65203659100061 Code APE : 3040Z - Construction de véhicules militaires de combat



50

60

70

80

90

100

110

120

2005 2006 2007 2008

� Panhard bénéficie d’un segment de marché dynamique.

� Le carnet de commandes s’élève fin 2006 à plus de 143 M€, soit plus de deux fois le chiffre d’affaires de 2006. Avec les tranches conditionnelles, il est de 360 M€.

� Un résultat opérationnel de l’ordre de 10 % du chiffre d’affaires.

Fig.1 Chiffre d’affaire de Panhard General Défense

La société est implantée sur deux établissements :

� Le siège social situé à Marolles en Hurepoix : 2 rue Panhard et Levassor – 91630 Marolles en Hurepoix

� L’usine de Saint Germain Laval : Z.I les Pralong – 42260 St Germain Laval

Fig.2 Situation géographique de Panhard General Défense

La société compte 350 salariés (280 salariés à Marolles, 70 à St Germain Laval).

� Marolles en Hurepoix : � Capacité d’assemblage importante de véhicules (35 000m² couverts). � Montage complet de véhicules



� Assemblage de sous-systèmes mécaniques (transmission, systèmes de

refroidissement, …) � Traitement de surface par cataphorèse � Peinture de véhicules complets � Essais (cage de FARADAY, bassin de navigation, rampes, dévers…) � 12 cabines d’essais moteurs � Soutien logistique

� Saint Germain Laval :

� Atelier très performant de tôlerie et constructions mécaniques, expertise dans le domaine des blindages.

� Atelier de montage des véhicules 4x4 � Découpe Plasma � Poinçonneuse Grignoteuse � Plieuse � Robot de soudure � Les éléments du PVP mécano soudés sont réalisés à Saint Germain Laval.

Le champ d’activité se divise en deux grands domaines :

� Armement : conception, étude, développement et validation, fabrication, vente et soutien logistique de véhicules blindés à roues en tant que maître d’œuvre, ensemblier des systèmes d’armes intégrés, mais aussi la remotorisation et revalorisation des véhicules et systèmes associés.

� Automobile : du fait de son ancienne appartenance au Groupe PSA, une diversification vers ce secteur d’activité s’est développée, tant au niveau études, essais qu’au niveau réalisation de sous-ensembles et d’ensembles en petites séries que la flexibilité de l’entreprise permet de gérer.

Avec une gamme de véhicules à roues jusqu’à douze tonnes, PANHARD General Défense a vendu plusieurs milliers d’engins tant sur le plan national, qu’à l’exportation où il est présent dans près de cinquante pays. La firme est leader dans les véhicules blindés à roues de moins de dix tonnes.

Fig.3 Présence internationale de Panhard General Défense



Ses principales dernières réalisations sont :

� Plus de 4700 véhicules gamme A, AML 60, AML 90 et leurs dérivés � Plus de 700 véhicules gamme B, ERC 90 LYNX, ERC 90 SAGAIE, VCR et leurs

nombreuses versions � 2300 VBL dans 16 pays dont plus de 1600 VBL en service dans l’armée

française, versions courtes et longues

La nouvelle orientation stratégique mise en place depuis 2001 a consisté à renouveler la gamme de produits et à réorganiser la production pour atteindre un niveau de productivité et de qualité correspondant aux standards les plus élevés du moment. Cet effort a vu l’aboutissement très prometteur de la sélection par le ministère français de la Défense du véhicule A4-AVL dans le cadre du programme PVP et ceci à l’issue d’une compétition des plus exigeantes.

L’ensemble de l’activité PANHARD est aujourd’hui guidé vers une amélioration permanente de la qualité.

La société possède les plus hautes certifications internationales : � l’AQAP 2110 est une norme OTAN liée aux spécificités du domaine de l’armement

qui impose aux différents produits des exigences particulières (durée de vie, durée de soutien, …).

� L’ISO 9001, qui permet d’attester de la qualité de l’activité automobile.

L’objectif majeur de ces certifications est de satisfaire les clients, en termes de productions et de prestations, qu’ils soient internes ou externes.

Panhard poursuit ses activités dans les domaines :

� Etudes et développements o Poursuite d’études relatives au VBL o Etudes d’accompagnement et études générales en amont o Participation à des coopérations au niveau Européen o Etudes automobiles

� Principales productions o Les VBL, tant pour l’Etat Major de l’armée de terre Française qu’à l’exportation o Les kits de remotorisation des véhicules des anciennes gammes o Des productions de pièces de rechange



� Soutien logistique

L’entreprise est en mesure de fournir les différents éléments d’accompagnement du soutien logistique tels que :

o Formation o Assistance technique o Documentation o Equipements de soutien

3. Organigramme de PANHARD General Défense

Représentation générale de la société Panhard General Défense dirigée par Monsieur Christian MONS.

Fig.4 : Organigramme de l’organisation de Panhard General Défense

4. Organigramme du service Système d’information

Mon stage s’est déroulé au sein du service Système d’information qui représente une partie du service Amélioration de la performance . Celui-ci est encadré par mon tuteur, responsable informatique de Panhard General Défense, Monsieur Olivier BEGUET. Mon rôle au sein de ce service était celui d’un administrateur chargé d’apporter des améliorations au niveau du réseau (ouverture sur le monde extérieur, amélioration de la bande passante, déploiement du WIFI), de travailler sur la sécurité du réseau et assurer la



veille technologique des solutions mises en place et d’effectuer la rédaction de procédures d’administration.

Fig.5 : Organigramme du service Amélioration de la performance



Présentation du travail demandé

5. Contexte

Les réseaux d’entreprise ne cessent d’évoluer et les technologies de sécurité permettent d’améliorer la productivité et la réactivité d’une entreprise de façon considérable. Internet est devenu une ressource importante pour les entreprises de même que la messagerie. Les accès vers ces ressources doivent être accessibles le plus rapidement possible afin d’optimiser les performances de travail. De plus les utilisateurs sont de plus en plus mobiles et nécessitent un accès aux ressources de l’entreprise depuis n’importe quel lieu. Mais ces ressources sont malheureusement victimes d’attaques virales ou d’intrusions importantes (SPAM, spyware, malware, attaque DoS, attaque DDoS…), c’est pour cela qu’une veille technologique est nécessaire afin d’offrir un maximum de fonctionnalités en toute sécurité. Lors de mon arrivée, j’ai intégré une équipe de cinq personnes, deux programmeurs travaillant sur l’ERP de l’entreprise, un technicien, un programmeur de base de données 4D et un administrateur, tous encadrés par mon tuteur de stage qui se trouve être le client de mes projets. Chacun a son propre travail mais nous sommes amenés à travailler ensemble lors de problèmes conséquents (attaque virale, défaillance du matériel, défaillance des serveurs …) ou pour gérer l’assistance utilisateur. Avec leur aide j’ai pu acquérir rapidement les connaissances de l’architecture et du fonctionnement du réseau. Durant mon stage, j’ai pu constater une réelle nécessité d’apporter des améliorations au réseau de l’entreprise, tant au niveau de la sécurité (déploiement général de l’antivirus, filtrage anti-spam, protection anti-spyware, sécurisation des données …), qu’au niveau des rédactions de procédures pour améliorer la réactivité des interventions du personnel ainsi que leur efficacité. Les projets dont j’ai la charge ont pour objectif d’améliorer la bande passante du réseau, la sécurité et d’apporter une solution d’accès aux ressources internes de l’entreprise pour les utilisateurs. A la remise du présent rapport, la partie WIFI n’a pas encore été étudiée, suite à des problèmes plus importants concernant la sécurité du réseau. Cette partie ne sera donc pas exposée dans le rapport.

6. Objectifs

Jusqu’à ce jour mon stage s’est articulé sur trois projets : � 1er projet : Mise en place d’un accès à la messagerie depuis internet

En ce qui concerne le premier projet, celui-ci m’a conduit à m’intéresser aux différentes techniques de sécurité existante en matière de communications sur internet. A étudier l’intégration d’un serveur dans un réseau existant, puis effectuer une recherche approfondie des solutions proposées par mon responsable afin de définir la solution répondant au mieux aux besoins et de faire l’évaluation d’un produit commercial. L’objectif fut de fournir un accès à 40 personnes pour fin juin.



Pourquoi une telle solution : Jusqu’à présent, les utilisateurs mobiles (commerciaux,

directeurs, …) travaillaient avec une boite aux lettres externe de type gmail ou Yahoo lors de leurs déplacements. La procédure de mise en place et la maintenance, représentaient un coût important, de même que l’utilisation pour l’utilisateur s’avérait être complexe. Nous verrons par la suite que la publication d’un serveur interne nécessitera une attention particulière concernant la sécurisation des données et les méthodes d’authentifications.

� 2ème projet : Mise en place d’un serveur de mises à jour Microsoft

J’ai été amené à m’intéresser au fonctionnement du déploiement par GPO de l’Active directory du domaine de la société et de connaître les différentes solutions logicielles proposées par Microsoft afin de procéder aux mises à jour nécessaires. Cette partie n’a pas nécessité de recherche spécifique pour effectuer un choix de logiciel, mais j’ai dû mettre en place une procédure afin d’améliorer le déploiement des mises à jour. L’objectif était de déployer la solution pour fin mai pour tous les postes de la société.

Voici la problématique qui a fait naître ce besoin : les utilisateurs utilisent internet pour leur travail, mais cet accès peut malheureusement être considérablement long dû à une charge importante de la bande passante. Il a donc été souhaité que les mises à jour effectuées par les postes puissent être centralisées pour améliorer la bande passante vers internet et être contrôlées afin d’améliorer la sécurité du réseau, tout cela sans perturber les autres applications ou flux dans le réseau.

� 3ème projet : Mise en place d’une solution anti-spam

J’ai effectué des recherches sur différentes solutions anti-SPAM, établi un tableau comparatif, soumis mes résultats à mon responsable, puis validé la solution répondant au mieux aux besoins. L’objectif fut d’obtenir un filtrage de 90% des spams.

La problématique qui s’est posée est la suivante : malgré l’application d’une règle anti-spam au niveau des clients de messagerie (Outlook 2003), les utilisateurs se voyaient toujours infestés de messages indésirables. Les spam engendrent une perte de temps considérable sur le temps de travail des utilisateurs, sur la maintenance pour résoudre les problèmes et un risque élevé d’infection. Ce qui implique un coût important pour la société que nous verrons par la suite.

Chaque projet doit être accompagné lors de son installation, son déploiement et sa

validation, d’un ensemble de procédures pour le personnel afin de les former dans un premier temps sur papier. Ces procédures doivent être rédigées de façon très claire, mais aussi apporter des réponses à des problèmes pouvant intervenir lors d’une installation ou configuration. L’objectif est de permettre au personnel de pouvoir par la suite utiliser les différents systèmes et être prêt en cas de défaillance.

En plus des compétences techniques, ce stage a eu pour objectif de me montrer le rôle

d’un administrateur systèmes et réseaux et l’importance du relationnel et de la communication dans l’entreprise. Beaucoup de problèmes sont liés à un manque d’informations, c’est pour cela que la mise en place de procédures et de notices est très importante. De même que, selon moi, la participation des utilisateurs ainsi que leur avis sont des maillons importants pour nous éclairer sur la façon d’améliorer l’efficacité du réseau.



7. Présentation du réseau

Cette partie à pour objectif de donner un aperçu général du réseau informatique de la société Panhard. Une description des serveurs qui ont participé aux différents projets sera présentée.

Fig.6 Architecture générale du réseau informatique

Il y a un niveau de sécurité limitant l’accès au réseau du site de Marolles et de Saint Germain depuis l’extérieur :

� Un pare-feu : un pare-feu assez complet proposant des filtres intéressants (blocage de site web, de mots clefs, SPAM, d’IP …).

Chacun des sites a un contrôleur de domaine : � Deux contrôleurs de domaine (primaire : DC1 et secondaire ) pour Marolles en

Hurepoix � Un contrôleur de domaine DC2 pour Saint Germain Laval

Les contrôleurs de domaine gèrent l’authentification des utilisateurs et des différentes machines à l’aide d’Active Directory. Ils distribuent des adresses IP automatiquement aux machines grâce au système DHCP et ils établissent les correspondances entre les adresses IP et les noms de domaines grâce au système DNS. En cas de défaillance des contrôleurs de domaine, un contrôleur de domaine secondaire prend le relais.

Les boites de messagerie sont gérées par le serveur de messagerie Exchange 2003. Le réseau est aussi équipé d’un serveur de données, d’un serveur d’impression et d’un serveur antivirus.



Les deux sites sont interconnectés via un tunnel VPN de 2Mb/s en symétrique. Les utilisateurs de Saint Germain Laval ont leur boite aux lettres sur le serveur de Marolles. D’autres serveurs ne sont pas indiqués sur le schéma, car ils ne contribuent pas à la réalisation des différents projets. Les serveurs qui ont participé activement à la mise en place et au fonctionnement des différents projets sont le serveur de messagerie , le contrôleur de domaine DC1 et le pare-feu . Les noms employés sont fictifs. Pour le domaine de la société nous utiliserons le nom de domaine « domaine.fr », mise à part l’adresse d’accès au Webmail OWA.

8. Impact des projets

1.1 Accès à la messagerie de l’entreprise via inter net

Ce projet était particulièrement attendu par les utilisateurs. Certains m’ont fait part de leur enthousiasme, car la configuration actuelle leur était trop complexe et inconfortable au niveau de l’utilisation. De plus un accès direct à leur messagerie de l’entreprise via internet ou Outlook leur permet de travailler comme s’ils étaient dans l’entreprise ce qui ne change en aucun cas leur habitude et ne peut que les satisfaire. Ce confort s’est aussi fait ressentir au niveau de l’administration grâce à un gain de temps des configurations serveurs et postes utilisateur.

Afin de constater le réel avantage qu’apporterait un accès à la messagerie de l’entreprise, je vais faire un comparatif entre l’ancienne configuration et la solution que j’ai mise en place. Pour le moment, je ne parle pas de la solution que j’ai utilisée car nous la verrons par la suite.

� Configuration initiale : Dans cette configuration, les messages reçus dans la boite à la lettre Exchange sont automatiquement redirigés vers le serveur de messagerie externe (Webmail).

Fig.7 Configuration initiale de l’accès à la messagerie

On peut noter plusieurs points négatifs à ce type de configuration :

� Double maintenance



� Aucun contrôle sur la messagerie externe � Utilisation compliquée pour l’utilisateur � Utilisation de la bande passante deux fois plus importante � Risques de pertes des messages plus élevés � Multiplicité des adresses mails

Pour remédier à ces différents problèmes, la solution consiste à permettre aux utilisateurs d’accéder directement au serveur de messagerie de l’entreprise grâce à un serveur Reverse Proxy. De plus le serveur de messagerie Exchange offre deux possibilités d’accès, une via un site web « Outlook Web Access » et une autre via le client Outlook 2003 grâce au protocole HTTPS et RPC.

Fig.8 Nouvelle configuration de l’accès à la messagerie

Dans cette configuration, le serveur de messagerie externe n’existe plus. Tout est centralisé dans le réseau interne de l’entreprise. Les utilisateurs se connectent directement à la messagerie Exchange (1) (3) par l’intermédiaire d’un reverse Proxy (2) dont la description sera faite par la suite.

Inconvénients :

� Les transmissions doivent être sécurisées, � Des procédures d’authentification sont nécessaires pour améliorer la sécurité, � L’intégration dans le réseau doit être transparente.

Ce tableau représente la comparaison entre l’ancienne configuration que nous nommerons « Redirection » et la nouvelle solution nommée « Accès direct » :

Temps de configuration des comptes Conséquences - Aucun contrôle sur le serveur externe

Redirection 30 min - Création d'un nouveau compte obligatoire

- Double maintenance

- Contrôle total de la maintenance (car internalisé)

Accès direct 5-10 min - Seul le serveur de messagerie de l'entreprise est utilisé

- Utilisation simple pour l'utilisateur Tableau.1 Impact d’un accès à la messagerie via internet



Cette amélioration se veut bénéfique pour le personnel en terme de confort mais aussi bénéfique pour la société, car cette configuration augmente sa productivité, grâce aux avantages spécifiés précédemment. Le temps gagné au niveau des accès et des configurations, est du temps gagné pour résoudre d’autres problèmes ou effectuer d’autres travaux.

1.2 Serveur de centralisation des mises à jour Micr osoft Cette solution était une nécessité pour le service informatique, car elle apporte une amélioration au niveau sécurité des postes utilisateurs, une meilleure gestion du déploiement sur les postes, et un confort d’utilisation internet pour les utilisateurs dû à l’amélioration de la bande passante. Nous verrons par la suite que le déploiement d’une telle solution n’est pas aussi simple que l’on pourrait le croire, car elle est à double tranchant. Malgré l’avantage au niveau théorique que cela peut apporter, nous constaterons qu’au niveau pratique, la configuration doit être bien étudiée. Je vais, comme dans la partie précédente, vous faire un comparatif entre l’ancienne configuration et la nouvelle solution, afin de comprendre l’impact que cela induit au niveau des performances du réseau et de l’entreprise.

Configuration initiale :

Fig.9 Configuration initiale du déploiement des mises à jour

Comme on peut le constater, lorsque tous les PC effectuent leur mise à jour, la bande passante vers internet est encombrée. Par ailleurs aucun contrôle des mises à jour ne peut être effectué à distance. La solution serait d’intervenir sur chaque poste pour effectuer un contrôle, ce qui n’est pas envisageable.



Les mises à jour permettant d’améliorer la sécurité des systèmes et le besoin de pouvoir contrôler la bonne installation de celles-ci, sont nécessaires. Pour répondre aux deux principaux problèmes évoqués précédemment, nous avons la possibilité de mettre en place un serveur interne qui va permettre :

� Dans un premier temps de centraliser le téléchargement des mises à jour à partir du serveur Windows Update. Ceci aura pour avantage de libérer la bande passante vers internet.

� Dans un second temps les mises à jour pourront être sous le contrôle des administrateurs, c'est-à-dire que nous aurons le choix de déployer ou non les mises à jour et de forcer l’installation de celles-ci sur les postes.

Fig.10 Nouvelle configuration du déploiement des mises à jour

Tableau comparatif de la configuration initiale et de la nouvelle :

Avantages Inconvénients

Contrôle des mises à jour compliqué Configuration

Initiale Pas d'administration serveur Risque plus important de failles de sécurité

Bande passante vers internet encombrée

Contrôle des mises à jour

Nouvelle Configuration

Amélioration de la bande passante vers internet Administration du serveur

Installation personnalisée des mises à jour

Tableau.2 Comparatif des configurations de déploiement des mises à jour

Les améliorations qu’une telle solution apporte, sont très intéressantes. En outre, une solution gratuite, fournie par Microsoft, permet de répondre aux besoins.



Ce logiciel, qui s’installe sur un serveur, se nomme WSUS (Windows Services Update Server). Le plus gros travail est de définir la configuration à adopter et la procédure de déploiement des mises à jour.

1.3 Solution anti –spam

Les SPAM sont une nuisance importante au sein d’une société ; Serveurs de

messagerie saturés, dégradation des performances réseau, problèmes de stockage, pertes de productivité des employés.

Après avoir recensé auprès d’une trentaine d’utilisateurs, le nombre de spam qu’ils

recevaient en moyenne par jour sur une période de deux semaines, j’ai pu obtenir le coût en moyenne du SPAM au sein de la société PANHARD General Défense. Ceci grâce à un calculateur du coût du spam d’un fournisseur (spécialisé dans la lutte anti-spam et proposant des solutions de type Appliance) :

Fig.11 Coût du spam sans filtrage



On constate que ces messages ne sont pas qu’une gêne à l’utilisation, mais engendrent un coût important pour la société. En utilisant une solution anti-spam et en admettant que seulement deux spam arrivent dans les boites aux lettres par utilisateur, le coût total du spam s’élèverait à :

Fig.12 Coût du spam avec filtrage

Le gain pour la société, en termes de coût, est très important. Le coût du spam est

réduit d’environ 91%. Dans ce cas, la mise en place d’une solution anti-spam, devient très avantageuse et

surtout nécessaire.



Organisation du travail effectué

9. Méthodologie Afin de mener à bien mes projets, j’ai suivi les axes suivants :

� Etude d’avant projet

Cette phase fut très importante. J’ai effectué un gros travail de recherche et d’autoformation. N’ayant pas eu de formation approfondie dans ce domaine durant mon cursus scolaire, la méthodologie et la logique acquises cependant durant mes études, m’ont permis d’apprendre très rapidement. Afin de comprendre et de définir au mieux les besoins du client, en l’occurrence mon tuteur, il m’a fallu comprendre le fonctionnement des éléments principaux du réseau, étudier les protocoles, étudier l’architecture du réseau et l’interaction entre chaque élément, pour lui soumettre la meilleure solution.

Après avoir défini les solutions, j’ai pu établir un planning (cf. annexe 1 : planning) pour mener à bien mes projets.

� Phase de réalisation et campagne d’essais

Cette phase représente toute la partie développement et test des projets. Nous verrons par la suite la méthodologie employée pour effectuer les tests, ainsi que la configuration choisie pour les différentes solutions.

� Validation La validation représente la fin des essais et le début du déploiement de la solution, ainsi que la rédaction des procédures d’installation, d’administration, et la formation du personnel informatique.

10. Responsabilités

Je suis en charge du suivi global des projets et je dois rendre compte régulièrement à mon responsable de l'avancée du développement. Je suis autonome et responsable des solutions que je mets en place, notamment en ce qui concerne la sécurité des déploiements, des installations et des données.



En plus des projets, on m’a attribué des tâches annexes, telles que la mise en place de Viewpoint, un logiciel de supervision réseau, des interventions auprès des utilisateurs, la vérification, la réalisation d’un audit sécurité afin de tester le risque d’infiltration dans le réseau et les risques internes etc.… Je suis aussi en charge de la sécurité du réseau. Je dois vérifier que le site ne présente aucune faille et mettre en place des solutions de sécurité supplémentaires (modifications des restrictions au niveau du pare-feu, modification des droits utilisateurs, …). Concernant l’achat de matériel, aucun investissement n’a été nécessaire, car le matériel disponible était largement suffisant. Seul l’achat d’une licence pour le Reverse Proxy à été nécessaire et a été effectué par mon responsable après lui avoir présenté les avantages. J’ai dû définir des solutions dans l’optique suivante : un maximum de performance, d’efficacité et de qualité pour un minimum de coût. J’ai donc travaillé dans cette direction, en accord avec mon responsable, afin de définir les meilleurs choix. Nous allons voir, dans la partie suivante, les solutions qui ont été choisies et pourquoi elles ont été choisies.

11. Solutions retenues

1.4 Reverse Proxy

Deux solutions ont été proposées par mon responsable. Après avoir étudié la compatibilité, le niveau de sécurité, les avantages et les inconvénients des deux solutions, j’ai pu définir la solution la plus avantageuse et débuter mon travail d’installation. Le cahier des charges spécifiait seulement l’utilisation du protocole RPC over HTTPS utilisé pour le client Outlook. Or, j’ai pu constater que le serveur exchange avait la possibilité de donner l’accès à la messagerie via un site web Outlook Web Access. Les deux systèmes étant publiés par le serveur web IIS du serveur de messagerie, ils ont tous les deux été déployés. Avantages d’un accès web :

- Hétérogène : il s’adapte à n’importe quel système car il utilise les navigateurs internet,

- Peu couteux : Pas d’installation supplémentaire sur les postes.

Avantages d’un accès client Outlook : - Simplicité d’utilisation : les utilisateurs n’ont pas de manipulations complexes, - Complet : toutes les fonctionnalités sont présentes, - Accès aux messages en hors ligne.

La solution RPC over HTTPS pour l’accès avec Outlook est autorisée pour les personnes ayant un ordinateur portable et un client Outlook. La solution Outlook Web Access est très utile pour les personnes n’ayant pas de client Outlook, ou ayant un problème avec leur client Outlook.



L’objectif est de trouver une solution capable de publier ces deux solutions à l’aide d’un reverse proxy en toute sécurité. Objectif : Publier et sécuriser l’accès à Outlook Web Access en HTTPS et le Protocole RPC over HTTPS. Pour qui ? : Les utilisateurs nomades de l’entreprise. Pour quoi ? : accéder aux mails professionnels de façon sécurisée et réduire les coûts de maintenance et de déploiement. Comment ? : À l’aide d’un serveur reverse proxy placé dans la DMZ de l’entreprise. Pourquoi ? : éviter un accès direct des clients au serveur de messagerie et vérifier le contenu des données. Pour répondre à toutes ces demandes, j’ai arrêté mon choix sur l’application serveur ISA Server 2006 version Standard . Tout d’abord, Qu’est ce qu’ISA server ? : ISA server est une application serveur qui unifie un pare-feu, un réseau privé Virtuel (VPN) et un proxy/reverse proxy. Elle fournit un accès sécurisé aux applications et aux données Microsoft comme Exchange ce qui permet de publier aisément les applications Outlook Web Access et le protocole RPC grâce au protocole TLS/SSLv3. Le protocole SSL/TLS est par exemple utilisé pour sécuriser les transactions bancaires (ex : achat sur internet). ISA server rajoute un niveau de sécurité avant l’accès au serveur de mail (Pare-feu -> ISA -> Pare-feu). Il existe deux éditions d’ISA server :

� Edition standard � Edition Entreprise

Les deux versions sont très proches, hormis certaines fonctionnalités supplémentaires sur la version Entreprise, mais celle-ci ne justifie pas son utilisation au sein de la société car les avantages ne s’appliquent que pour des réseaux de grande envergure voulant publier des baies de serveurs et ayant un nombre d’utilisateurs plus important. J’ai donc travaillé sur la version Standard. Dans les deux éditions, ISA server intègre un filtre applicatif qui vérifie la couche des applications ce qui permet de réduire les risques et les coûts liés à la sécurité et éliminer l’influence négative des logiciels malveillants et des pirates. Le filtrage utilisé pour la publication d’OWA et du RPC est le filtrage HTTP. Rappel sur les différentes couches OSI :

Fig.13 Modèle OSI



La couche applicative est le point de contact entre l'utilisateur et le réseau. C'est donc elle qui va apporter à l'utilisateur les services de base offerts par le réseau, comme par exemple la messagerie. Le fait d’analyser le contenu de ces données augmente la sécurité du réseau et du trafic.

Fig.14 Filtrage applicatif

Il est un complément au pare-feu actuel de la société, car celui-ci n’assure que le filtrage au niveau des couches 1 à 6 du modèle OSI, tandis que le filtrage applicatif assure un filtrage au niveau de la couche 7. Les options suivantes sont disponibles dans le filtre HTTP :

� Limiter la taille maximale des en-têtes (header) dans les requêtes http � Limiter la taille de la charge utile (payload) dans les requêtes � Limiter les URLs qui peuvent être spécifiées dans une requête � Bloquer les réponses qui contiennent des exécutables Windows � Bloquer des méthodes HTTP spécifiques � Bloquer des extensions HTTP spécifiques � Bloquer des en-têtes HHTP spécifiques � Spécifier comment les en-têtes HTTP sont retournés � Spécifier comment les en-têtes HTTP Via sont transmis ou retournés � Bloquer des signatures HTTP spécifiques

Pour la publication d’OWA et du RPC, les options ont été laissées par défaut, mis à part le blocage des extensions où une certaine liste a été définie.



Les avantages d’ISA server, en plus de ceux cités auparavant, sont nombreux :

� Outils complets de publication (Outlook web Access, RPC over HTTPS, Sharepoint…)

� Simplification de l’administration grâce aux assistants � Mise en cache Web (Améliore la bande passante) � Publication de plusieurs serveurs avec une IP publique � Version d’évaluation complète de 180 jours. � Sécurisation des données et des accès :

o Cryptage des données de bout en bout grâce au SSL o Formulaires d’authentification : ce qui permet d’éviter d’authentifier

l’utilisateur sur le serveur de messagerie. o Gestion du protocole LDAPS pour communiquer avec l’Active Directory

(tout en étant hors du domaine), ce qui permet d’effectuer une vérification de l’utilisateur avant de lui donner l’accès au serveur de messagerie.

La sécurité proposée par le serveur fut un critère de choix important, car nous ne pouvions permettre des pertes d’informations ou des risques d’infiltration. Grâce au serveur ISA nous rajoutons une seconde couche de sécurité en plus du Pare-feu et pouvons mettre en place des communications SSL. Pour les besoins actuels seule la partie proxy/Reverse proxy a été étudiée. Le fait que la solution doit être installée en DMZ ne permet pas de profiter des avantages du pare-feu et du VPN mais pourra être bénéfique pour des perspectives futures. Cela ne supprime aucunement le filtrage applicatif web qui, dans notre cas, est le seul qui nous est utile. De plus ISA intègre des Modèles réseau qui permettent en quelques clics de configurer le serveur selon 4 configurations dont une en DMZ. Le choix d’intégrer le serveur ISA dans cette partie du réseau n’est pas anodin. En effet le fait de placer le serveur en DMZ n’engendre aucune modification au niveau du réseau et elle ajoute une couche de sécurité supplémentaire. Pourquoi une couche de sécurité supplémentaire ? Pour comprendre cela je vais expliquer ce qu’est une DMZ : Une DMZ, zone démilitarisée, est un sous-réseau isolé par un pare-feu. Elle est utilisée pour installer des machines devant être accessibles depuis internet. En cas de compromissions d’une machine en DMZ, l’accès au réseau interne est encore contrôlé par le pare-feu.

Fig.15 Avantage d’une DMZ



Le schéma démontre l’utilité d’une DMZ. Aucun accès n’est possible vers le réseau interne (LAN), que ce soit du réseau WAN vers le LAN que de la DMZ vers le LAN. Les ports de communication entre la DMZ vers le WAN sont ouverts, mais, ce qui change, est le fait que des ports entre le réseau WAN et DMZ peuvent aussi être ouverts. Rien ne nous empêche d’ouvrir les ports entre la DMZ et le LAN, mais il faut les limiter et les sécuriser afin de minimiser les risques. Pour le bon fonctionnement du serveur ISA, le port 443 (HTTPS) doit être ouvert dans les deux sens DMZ < > WAN. De même que les ports 443 et 3269 (LDAPS) doivent aussi être ouverts entre la DMZ et le LAN. Nous verrons dans la partie « Réalisation » la méthode à appliquer pour ouvrir les ports d’un pare-feu.

Comme on peut le constater, ISA server est une solution complète et adaptée aux systèmes Windows, ce qui facilite grandement l’intégration et la configuration de l’application et apporte un niveau de sécurité élevé.

1.5 anti-SPAM

Objectif : Supprimer les messages indésirables (SPAM). Pour qui ? : La sécurité des postes, les utilisateurs et l’administration. Pour quoi ? : supprimer les SPAM des clients Outlook des utilisateurs. Comment ? : À l’aide d’une solution anti-spam de type Appliance ou logiciel. Pourquoi ? : minimiser le risque de virus par courriel, l’utilisation de la bande passante et améliorer la productivité des employés. Il existe plusieurs types de solutions anti-spam.

� Solution Type I : Les logiciels installés sur les postes clients.

Ici, le SPAM arrive jusqu’au poste de l’utilisateur avant d'être interprété et l’utilisateur passe beaucoup de temps sur Internet à essayer de rapatrier des emails qui seront finalement interprétés comme des SPAM.

Avantage :

� Généralement le logiciel anti-spam est gratuit Inconvénients :

� Le logiciel anti-spam doit être installé sur tous les postes � Les SPAM arrivent sur les postes avant analyse � Le logiciel ne peut gérer les faux positifs (il oblige à regarder régulièrement le

dossier de quarantaine).



� Solution Type II : Nous avons les logiciels installés sur le serveur de messagerie ou les solutions Appliance (matériel et logiciel).

Concernant cette nouvelle catégorie de logiciels, la solution anti-spam est installée sur le serveur de messagerie de l’entreprise ou en amont de celui-ci, avec la mise en place d'Appliance en DMZ par exemple. Ici, le filtrage s’effectue dès l’arrivée du message sur le réseau de l’entreprise, ainsi les utilisateurs ne perçoivent pas les messages non sollicités.

Avantages :

� Évite l'installation sur tous les postes et l'encombrement du réseau interne � Peut vérifier la conformité du protocole � Permet d’améliorer la solution conformément à son besoin (configuration

personnalisée) Inconvénients :

� Nécessite un logiciel ou matériel supplémentaire � Ressources nécessaires à l'installation, l'administration et la gestion � Mises à jour et maintenance nécessaires � Deux équipements nécessaires (pour la disponibilité du service) � Les SPAM encombrent votre bande passante

� Solution Type III : Les logiciels Anti-spam externalisés (ASP)

Externaliser son logiciel Anti-SPAM est une solution intéressante, car elle permet à l’entreprise, dans un premier lieu, de ne pas être pénalisée et encombrée par les SPAM. En effet, les logiciels Anti-SPAM ASP offrent la possibilité, à la fois, de libérer la bande passante utilisée par l’entreprise, mais également, d'éviter tout investissement humain.

Avantages : � Évite l'installation sur tous les postes et l'encombrement du réseau interne � Allège la bande passante et le serveur de messagerie � Assure une haute disponibilité du service messagerie � Pas d'installation, de ressources affectées, de mises à jour � Délai de mise en œuvre très court � Sécurise l’entreprise (limite les flux entrants)

Inconvénients :

� Les possibilités de personnalisation de la configuration sont limitées

Suite aux différentes solutions exposées et à l’étude de l’existant, j’ai pu effectuer le choix approprié pouvant répondre aux besoins (coût minimum, taux de SPAM minimum). Aucun budget n’étant disponible, la solution type III se voit écartée dans le choix d’une solution.



En étudiant l’existant, j’ai pu constater que le serveur Exchange de la société, installé depuis janvier 2007, avait la possibilité d’effectuer un filtrage des messages, grâce au filtre IMF (Intelligent Message Filter) et de les gérer à l’aide du logiciel de gestion des SPAM IMF companion. Nous nous retrouvons dans la catégorie solution de type II . Le filtre étant déjà intégré au serveur, aucun coût supplémentaire n’a été nécessaire. Malgré les inconvénients que cette solution implique, particulièrement les faux positifs, nous avons validé ce choix que nous avons couplé avec les fonctionnalités de blocage du pare-feu afin d’optimiser le filtrage.

1.6 Serveur de centralisation des mises à jour

Objectif : Améliorer la bande passante vers internet et contrôler les mises à jour des postes. Pour qui ? : La sécurité des postes et l’administration. Pour quoi ? : Mettre à jour les postes utilisateurs. Comment ? : À l’aide d’une solution Microsoft gratuite : WSUS (Windows Server Update Services. Pourquoi ? : Limiter le risque de failles sur les postes et la surcharge de la bande passante vers internet. La solution était déjà définie. En effet, Microsoft proposait un logiciel gratuit intitulé WSUS permettant de répondre aux besoins. La partie la plus importante de ce projet fut la mise en place d’une procédure de déploiement permettant d’optimiser la distribution des mises à jour. Nous verrons dans la partie « Réalisation » le déploiement choisi ainsi que les différentes configurations et solutions choisies.



12. Contraintes

1.7 ISA server

� Délai : 2/3 mois pour définir la solution, effectuer les tests en interne et commencer les

tests en externe. � Technique :

� La messagerie sécurisée doit être simple à utiliser et accessible par tout type de navigateur web et/ou le client de messagerie (Internet Explorer, Mozilla, Outlook …)

� La technologie de mise en œuvre devra respecter les standards suivants : o Protocoles TCP/IP, LDAP, RPC, HTTP avec TLS/SSL v3 o Certificats de chiffrement X 509

� Le serveur doit être capable d’encaisser une grosse charge de travail afin d’apporter aux utilisateurs un confort d’utilisation et un accès rapide.

� La station accueillant le serveur ISA doit répondre à certains critères : Matériel Logiciel PIII 733MHz Windows Server 2003 R2 512 Mo de mémoire Windows Server 2003 web edition 6Go Une carte réseau

� L’intégration doit se faire dans la DMZ

� Budget : Les contraintes budgétaires sont orientées « utilisateur » spécifiant qu’il ne faut pas de coût d’installation pour l’utilisation de la messagerie au niveau de son poste de travail.

1.8 Serveur WSUS

� Délai : 2 mois, pour effectuer les tests et le déploiement de la solution. � Technique :

Configuration matérielle minimum Matériel Logiciel PIII 733MHz Windows Server 2003 R2 512 Mo de mémoire Windows Server 2003 web edition 6Go

Une carte réseau

� Coût : humain. Nécessite un suivi des mises à jour.

1.9 IMF Anti-SPAM

� Délai : 1 mois pour définir la solution et la mettre en place. � Technique : utilisation du filtre IMF du serveur Exchange. � Coût : Suite à une revue en baisse du budget, les recherches ont dû se faire sur des

solutions gratuites. Un coût humain est aussi à notifié car une solution non payante nécessite une maintenance plus importante.



Réalisation

13. ISA server

1.10 Fonctionnement

� Fonctionnement du point de vue Utilisateur :

Fig.16 Intégration du serveur ISA server 2006

Pour comprendre au mieux les chapitres qui vont suivre, cette partie va expliquer du point de vue utilisateur, le fonctionnement du système d’accès à la messagerie. Pour OWA (cf. Annexe 2 : Notice d’accès OWA) :

� L’utilisateur saisit l’adresse suivante dans son navigateur : https://mailhost.panhard.fr/exchange

� Un certificat au nom de la société s’affiche et doit être validé afin de crypter la communication.

Remarque : Le certificat peut être installé sur la machine afin de ne plus avoir à le valider par la suite (cf. Annexe 6 : Configuration OWA – Règles à respecter – dernière partie).

� Un formulaire d’authentification apparaît, il faut saisir son identifiant et son mot de passe. Remarque : un cadenas affiché sur le navigateur permet d’attester que le site est sécurisé.

� Si les informations sont valides l’utilisateur va être redirigé vers le site OWA.

Pour Outlook (cf. Annexe 3 : Accès au serveur de messagerie via Outlook) : � L’utilisateur exécute son client Outlook � Il doit saisir son identifiant et son mot de passe � Si les informations sont valides l’utilisateur recevra ces mails via le protocole RPC

over HTTPS.



� Fonctionnement du point de vue Technique : Cette partie a pour objectif d’expliquer ce qu’il se passe réellement lorsque l’utilisateur veut accéder au serveur de messagerie.

� (1) Dans un premier temps, l’utilisateur commence la communication en envoyant une demande au serveur ISA. Dans notre situation, lorsque l’utilisateur saisit l’adresse https://mailhost.panhard.f/exchange, la requête est redirigée sur l’IP publique de la société. Ensuite le pare-feu est paramétré pour effectuer un « forward » des requêtes entrantes sur le port 443 HTTPS de l’IP publique vers le serveur ISA.

� (2) La passerelle ISA va, suite à la requête, générer une clé publique à l’aide d’’un certificat et la renvoyer au client. Le serveur ISA possède un certificat intégrant une paire de clé privée/publique et correspondant à une autorité de certification, c’est un certificat auto-signé. Nous verrons par la suite la signification de clé privée et publique et d’autorité de certification.

� (3) le poste client reçoit la clé publique qui va se présenter sous forme d’un certificat. Ceci va lui permettre d’authentifier que le serveur qu’il a contacté est correct. Le certificat va fournir des informations sur le serveur, l’autorité de certification, la date de validité, le nom de la société, son lieu. Si le certificat est correct, le client va pouvoir le valider et les données générées vont être retransmises au serveur ISA.

� (4) Le serveur ISA va maintenant utiliser sa clé privée pour crypter les données

réceptionnées et les renvoyer au client. � (5) Les données reçues par le poste client vont être décryptées en utilisant la clé

publique précédente et comparées par rapport à la première requête. Si le message correspond, cela veut dire que le destinataire est le bon, la connexion SSL est établie. Un imposteur n’aurait pas pu connaître la clé privée du serveur et par conséquent aurait été incapable de crypter le message.

Fig.17 Encapsulation http sur SSL/TLS

� (6) Le tunnel de communication SSL étant établi, le serveur ISA va soumettre au

client un formulaire d’authentification.

� (7) Après avoir saisi et validé les informations d’authentification, celles-ci vont être envoyées au contrôleur de domaine afin de vérifier qu’elles sont correctes (Le



processus d’activation de la communication SSL est le même que pour l’accès client<>Serveur ISA sauf que le protocole utilisé est le LDAPS : port 3269 ).

Fig.18 Encapsulation LDAP sur SSL/TLS

� (8) Si les informations d’authentification ne sont pas valides, l’accès sera refusé.

Si elles le sont, alors le serveur ISA va envoyer les credentials au site Web OWA. La communication est aussi cryptée en SSL entre ISA et le serveur de messagerie. Le principe est le même que la communication entre le poste client et le serveur ISA.

� (9) La vérification étant faite sur le contrôleur de domaine, le site web OWA va,

une deuxième fois, vérifier que les informations sont correctes en utilisant une authentification de base (domaine\login ; mot de passe), que nous verrons par la suite, et donner l’accès à la messagerie.

Pour le protocole RPC, le principe est identique, mis à part que l’utilisateur n’a pas à se connecter via une interface web.

1.11 Architecture du serveur ISA

Fig.19 Architecture ISA server



Le serveur ISA propose un nombre important de filtrages applicatifs. Pour nos besoins, seul le filtrage Web Proxy nous intéresse, étant donné que nous utilisons le protocole HTTPS.

1.12 Interface du serveur ISA

Le serveur offre une interface très ergonomique et permet, à l’aide d’assistants, de configurer très facilement les accès aux données internes en HTTPS.

Fig.20 Interface ISA server

Comme on peut le voir, deux règles sont créées. Nous verrons par la suite comment les mettre en place.

1.13 Pré-requis pour le déploiement

Les pré-requis sont les suivants : � Un nom public Internet :

Lorsque l’on souhaite publier un site web sur internet il faut avoir une IP publique. Une IP représente l’adresse réseau d’une machine. C’est celle qui va permettre de transmettre les informations entre ordinateurs. Dans ce cas, nous parlons d’IP publique, car elle est visible sur le web. Les adresses IP sont numériques. Afin de faciliter l’accès, il est nécessaire de convertir cette IP au format textuel du type www.domaine.com, que nous appelons un alias. Cet alias est défini dans le DNS public de la société, c’est à dire auprès de notre fournisseur d’accès internet. Un DNS permet de mettre en relation un utilisateur avec le site demandé, c'est-à-dire que, si un utilisateur veut se connecter sur www.domaine.com, le DNS se chargera de le rediriger vers l’adresse IP publique concernée.



Fig.21 Redirection du DNS public

Après avoir reçu des informations concernant une configuration antérieure d’un alias DNS, auprès de mon responsable, je n’ai eu aucune modification à effectuer au niveau du DNS public. L’adresse définie dans le DNS public, et actuellement utilisée pour accéder à la passerelle ISA, est le FQDN (Nom de domaine pleinement qualifié) suivant : mailhost.panhard.fr Dans ce cas, lorsque les utilisateurs saisiront l’adresse https://mailhost.panhard.fr, ils seront redirigés vers l’IP publique de la société. Nous avons vu que nous avions la possibilité de publier plusieurs serveurs ou applications avec une seule IP publique. En effet, certaines sociétés ont plusieurs IP publiques ce qui leur permet d’assigner une IP pour chaque serveur, mais cela implique un coût important. Grâce au serveur ISA nous pallions cette faiblesse en rajoutant des extensions au FQDN « mailhost.panhard.fr ». En effet l’accès vers :

� Outlook Web Access se fait par l’adresse : https://mailhost.panhard.fr/exchange � RPC sur HTTPS se fait par https://mailhost.panhard.fr/RPC.

� Des certificats électroniques :

Jusqu’à présent, je n’ai parlé que très peu des certificats x509. Pourtant ils ont une importance capitale dans le fonctionnement d’ISA server. En effet, c’est grâce à eux que l’utilisation du protocole SSL est possible. Il existe plusieurs versions du protocole SSL (SSLv1 SSLV2 SSLv3 TLS 1.0). Dans notre cas nous allons utiliser la version SSLV3/TLS1.0 car elle offre aujourd’hui le meilleur niveau de sécurité. Il est assez simple de vérifier qu’un site utilise le protocole SSL. Tout d’abord l’URL qui est saisie est en HTTPS et non en HTTP, le S signifiant SSL/TLS et sur les navigateurs, des

cadenas sont affichés .



Un certificat SSL est un fichier qui s'installe sur un serveur internet ; c’est une couche optionnelle se situant entre les couches d’application et de transport du modèle OSI.

Fig.22 couche SSL

Il comprend une clé privée pour crypter les données et une clé publique pour les décrypter. Ce certificat a pour but unique de sécuriser l'envoi de données d’un serveur de publication, en l’occurrence Exchange. Il existe plusieurs niveaux de cryptage, de 40 à 256bits. Plus le niveau de cryptage est élevé, plus le niveau de confidentialité est important et empêche de briser le certificat. Une étude effectuée par le groupe Yankee pour la société Verisign (référence en matière de certificat) montre que le cryptage des certificats inférieur à 128bits comporte des risques plus grands de piratage.

Tableau.3 Temps nécessaire pour violer un cryptageSSL

Grâce au serveur ISA le cryptage en 128 bits est forcé. Un certificat a une certaine structure que l’on peut retrouver dans l’annexe suivante (cf. Annexe 4 : Structure d’un certificat x509).



Le certificat va assurer : � L’authentification : dans SSLv3.0/TLS1.0 l’authentification du serveur est obligatoire.

Elle a lieu à l’ouverture de la session. Elle emploie pour cela des certificats conformes à la recommandation X.509 v3. Cela permet au client de s’assurer de l’identité du serveur avant tout échange de données.

� La confidentialité : Elle est assurée par des algorithmes de chiffrement symétriques. Bien que le même algorithme soit utilisé par les deux parties, chacune possède sa propre clé secrète qu’elle partage avec l’autre. Ce protocole utilise l’algorithme RSA (Rivest, Shamir et Adlema), un standard utilisé pour le cryptage des données et la signature de messages électroniques. Cet algorithme est très utilisé pour l'authentification et le cryptage des données dans le domaine informatique.

� L’intégrité : Elle est assurée par l’application d’un algorithme de hachage aux données (SHA ou MD5) transmises. L’algorithme génère, à partir des données et d’une clé secrète appelée code d’authentification de message, une suite de bits. Cette suite sert de signature pour les données. Ainsi tout changement appliqué aux données, implique un changement de la suite de bits générée par l’algorithme de hachage, et en conséquence, provoque la génération d’un message d’erreurs, côté récepteur, du fait que les deux suites sont différentes.

1.14 Création des certificats

Ils peuvent être émis par une autorité de certification tierce approuvée ou un certificat d'infrastructure à clé publique Microsoft Windows en utilisant les services de certificats, ou peuvent être auto-signés. Pour minimiser les coûts d’utilisation d’ISA server nous avons opté pour la création de certificats auto-signés. Nous utilisons un logiciel de cryptographie gratuit, qui va nous permettre de créer nos certificats. Afin de bien comprendre la création des certificats, je vais expliquer ce qu’est une autorité de certification. Une autorité de certification est un organisme qui va être chargé de créer, délivrer et gérer des certificats électroniques. Dans nos navigateurs internet, plusieurs autorités de certification sont installées (Verisign, thawte, Globalsign…), représentées par des certificats. Les navigateurs ont les autorités de certificat de ces organismes, ce qui permet de valider automatiquement tout certificat émanant de ces autorités. Dans notre cas, nous utilisons le logiciel OpenSSL . Vous retrouverez la méthodologie pour créer un certificat (cf. Annexe 5 : Création d’un certificat auto-signé). Etant donné que nous n’avons pas d’autorité de certification reconnue par les navigateurs, la solution a consisté à créer un certificat auto-signé, ce qui veut dire que le certificat représente l’autorité de certification et intègre les rôles d’authentification client et serveur. Ceci va nous donner l’avantage suivant : lorsque l’utilisateur va se connecter au site web, la première fois, il aura un message d’erreur, ce message pourra être supprimé en installant le certificat dans le gestionnaire de certificat du navigateur en tant qu’autorité de confiance. A la prochaine connexion, l’utilisateur accèdera directement à la page d’authentification, car le navigateur pourra reconnaître que le site visité est de confiance.



Les étapes (1) à (6) vues dans la partie Fonctionnement du point de vue technique du titre 1.10 Fonctionnement, se feront automatiquement. Une règle très importante doit être appliquée lorsque l’on créé des certificats. Il faut que le nom du certificat corresponde au nom du site que l’on publie. Dans notre cas le FQDN du site, c'est-à-dire « mailhost.panhard.fr », donc le certificat, devra être attribué à « mailhost.panhard.fr ». De même pour l’authentification LDAPS, le certificat doit être au nom complet du contrôleur de domaine, dans notre cas « DC1.domaine.fr ». Pour déployer le serveur de messagerie, deux certificats ont été créés :

� Un certificat au nom de « mailhost.panhard.fr » permettant de sécuriser la communication entre le client et le serveur Exchange avec comme intermédiaire la passerelle ISA.

Fig.23 Certificat « mailhost.panhard.fr »

� � Un certificat au nom de « DC1.domaine.fr » pour sécuriser les informations

d’authentification (Serveur ISA <> Contrôleur de domaine).

Fig.24 Certificat « DC1.domaine.fr »

On peut voir que les deux certificats ont une clé privée. Cette clé doit être présente sur le serveur effectuant l’authentification du client pour activer la transaction SSL, car c’est elle qui va crypter les données.



De plus les certificats « mailhost.panhard.fr » et « DC1.domaine.fr » doivent être installés sur le serveur ISA car, comme on l’a vu précédemment, pour que la communication SSL soit active, il faut que les certificats soient installés sur la machine.

1.15 Configuration du serveur Exchange

Avant toute manipulation, il faut installer le certificat « mailhost.panhard.fr » (cf. annexe : installation d’un certificat). Exchange est le serveur qui va fournir les applications permettant d’accéder à la messagerie. Il y a deux configurations à effectuer. Une pour activer le protocole SSL pour Outlook Web Access et une autre pour activer le protocole RPC over HTTPS. Cette configuration s’effectue dans le gestionnaire de site IIS.

Fig.25 Gestionnaire de site web IIS

La configuration d’Outlook Web Access et du protocole RPC nécessitent un certificat, ici nous utilisons le certificat « mailhost.panhard.fr », car le site web OWA publié, ainsi que le protocole RPC, seront accessibles via l’adresse mailhost.panhard.fr .

Fig.26 Configuration SSL IIS



L’étape suivante consiste à forcer l’utilisation du SSL ainsi que le cryptage des données en 128Bits :

Fig.27 Forçage du SSL et cryptage à 128bits

En plus de la configuration SSL, il faut configurer l’authentification entre le client et le Serveur Exchange en authentification de base (Login: DOMAINE\User ; Pass : *******). Dans notre cas, cette authentification correspondant à celle entre le serveur ISA et le serveur Exchange, étant donné que le client s’authentifie sur le serveur ISA.

Fig.28 Option Authentification de base

Il est indiqué que les mots de passe sont envoyés en clair. Ayant installé un certificat et forcé le cryptage SSL à 128bits, les données sont donc cryptées. L’annexe 6 : Configuration OWA, donne la configuration détaillée pour paramétrer le SSL pour OWA et le protocole RPC.



1.16 Configuration du contrôleur de domaine

Il y a très peu de modifications à effectuer. Pour activer le protocole LDAPS (permet d’authentifier les utilisateurs via un tunnel sécurisé), il suffit d’installer un certificat sur le contrôleur de domaine (cf. Annexe 6 : Configuration OWA – 1.Installer un certificat) ayant le même nom FQDN en l’occurrence « DC1.domaine.fr ». Le redémarrage de la machine a dû être nécessaire. Afin de ne pas gêner les utilisateurs, le redémarrage a été effectué le midi (environ 10mn d’arrêt). A l’aide du logiciel « Ldp.exe » natif au contrôleur de domaine, le bon fonctionnement du protocole LDAPS a pu être vérifié :

Fig. 29 Vérificateur de connexion LDAPS

La connexion est établie sur le port 3269, car celui-ci permet de communiquer avec le catalogue global de l’Active Directory en mode sécurisé (cryptage à 128bits).

1.17 Configuration du serveur ISA

Configuration du Modèle réseau : dans notre cas, en mode Carte réseau Unique, c'est-à-dire en DMZ. Le serveur Reverse Proxy devait être intégré dans la DMZ. Ce fut l’un des critères de choix pour la sélection du serveur ISA. Un assistant très efficace est disponible pour mettre en place, sans efforts administratifs, les topologies réseau classiquement utilisées sur un pare-feu. Il suffit de lancer l’assistant et en trois clics de souris, les règles permettant de déployer les serveurs de l’entreprise sur internet, sont appliquées.

Fig.30 Modèle réseau CARTE UNIQUE



Une seule carte réseau est nécessaire, le trafic entrant et sortant s’effectue sur la même carte réseau. Configuration (cf. Annexe 7 : Configuration du serveur ISA) :

� Installation des certificats « mailhost.panhard.fr » et « svmdc.scmpl.fr » : ces certificats doivent être installés sur le serveur ISA car ils sont nécessaires pour l’authentification du client et de l’authentification d’ISA vers les serveurs Exchange et DC.

� Configuration d’un port d’écoute SSL : c’est le port que le serveur ISA devra

écouter pour intercepter les informations. Le port d’écoute SSL est le 445. Forçage du cryptage 128bits.

� Configuration de l’accès au contrôleur de domaine : afin d’authentifier les utilisateurs

� Création des groupes d’utilisateurs : les utilisateurs ont été définis par mon responsable et le directeur des ressources humaines.

� Création des planifications d’accès : ces accès ont été étudiés en fonction des

utilisateurs afin de déterminer les horaires d’accès pour chacun.

� Configuration de la publication d’Outlook Web Acces s : cette configuration va permettre de déployer sur internet le site web Outlook Web Access et de configurer un formulaire d’authentification. J’ai effectué une personnalisation du formulaire afin qu’il s’adapte à la société.

� Configuration de la publication du RPC sur HTTPS : la configuration est

similaire à celle d’OWA, à l’exception de l’adresse d’accès.

� Configuration en Workgroup : ISA server ne doit pas faire partie du domaine, le fait de le mettre en workgroup, rajoute une couche de sécurité.

� Modification du fichier hosts : le serveur étant isolé du réseau interne et n’ayant

aucun accès au serveur DNS, il a fallu modifier ce fichier et indiquer la traduction du format texte des serveurs Exchange et du DC en IP.

� Configuration de la carte réseau : le serveur devant être accessible à tout

moment, il a fallu définir une adresse IP fixe.

� Configuration de la mise en cache : ceci permet de mettre en cache les images du site web OWA ce qui permet d’alléger la bande passante sur le réseau de la société.

� Test de la sécurité et configuration du serveur : avant de commencer les tests,

des outils m’ont permis de vérifier que le serveur en lui-même était bien sécurisé et configuré. Pour cela j’ai utilisé les outils Microsoft baseline Security Analyzer 2.0.1 ce qui permet de vérifier la sécurité du serveur et Isa Server Best Practices Analyzer Tool qui permet de vérifier la configuration du serveur.



Des séries de tests ont été effectuées afin de vérifier le bon fonctionnement de chaque serveur.

1.18 Tests Réalisés

� Tests internes

1er test :

Vérification du fonctionnement sur l’intranet de l’accès en HTTPS au site web Outlook Web Access :

� Tests d’accès via l’adresse https://serveur_messagerie/exchange : Comme on peut le constater l’adresse n’est pas celle indiquée sur le certificat « mailhost.panhard.fr ». Cela ne pose aucun problème depuis le réseau de l’entreprise. Il suffit d’accepter le certificat. Le fait que le certificat apparaîsse lors de la validation de l’adresse, prouve que la communication sécurisée SSL a été amorcée. Comme je l’avais déjà notifié auparavant, nous pouvons nous assurer que la communication est sécurisée en vérifiant la présence de cadenas sur le navigateur ainsi que la saisie de HTTPS en place de http. Pour être certain que la communication s’est bien effectuée en SSL, j’ai, à l’aide de Microsoft Network Monitor, analysé les trames :

Fig.31 Résultat de l’analyse de trames pour les tests internes

Afin de faciliter l’accès aux utilisateurs, j’ai paramétré la redirection HTTP vers HTTPS au niveau des fichiers d’erreurs. Ayant eu quelques complications à effectuer la redirection à l’aide du langage .ASP, j’ai décidé de modifier les fichiers HTML d’erreurs et d’intégrer un rafraîchissement de la page qui redirige l’utilisateur vers la bonne adresse.

<meta HTTP-EQUIV="REFRESH"

CONTENT="0;URL=https://serveur_messagerie

/Exchange">

<meta HTTP-EQUIV="REFRESH"

CONTENT="0;URL=https://serveur_messagerie

/Public">

2ème test :

Vérification de l’accès au contenu de la messagerie via Outlook en RPC sur HTTPS. Configuration d’un client Outlook 2003 (cf. Annexe 8 : Configuration du client Outlook)

� Vérification de l’accès via HTTPS avec la commande : Outlook /rpcdiag .



Fig.32 Validation de l’accès RPC over HTTPS

Le client Outlook accède au serveur Exchange via internet avec un tunnel SSL (HTTPS). En cas de mauvaise configuration, nous aurions eu dans la partie connexion, du protocole TCP/IP.

3ème test :

Vérification de la communication entre le serveur ISA et le Catalogue Global du DC :

� Test effectué à l’aide de « Ldp.exe ». � Test effectué directement sur le serveur ISA en ajoutant des utilisateurs du

domaine Panhard dans des groupes utilisateurs d’ISA.

Les tests ont été concluants.

4ème test : Ce stade a permis de valider le fonctionnement d’ISA server avec les protocoles HTTPS et LDAP (authentification non sécurisée) dans un premier temps. Outils nécessaires :

� Un poste utilisateur qui fait office de client avec une modification du fichier HOSTS afin de rediriger l’adresse https://mailhost.panhard.fr/exchange sur l’IP du serveur ISA.

� Microsoft Network Monitor : logiciel de capture de trame pour vérifier le trafic du serveur ISA.

Fig.33 Schéma de test avec ISA server 2006 en interne



Description :

(1) L’utilisateur saisit l’adresse du site https://mailhost.panhard.fr/exchange (2) Le fichier host a été modifié afin de rediriger la requête vers le serveur ISA. Si la

modification n’était pas faite, l’utilisateur aurait été redirigé automatiquement vers l’IP publique de la société.

(3) et (4) Le serveur ISA reçoit la requête et va établir la connexion SSL pour permettre à

l’utilisateur de s’authentifier. (5) Le serveur ISA fait une vérification des credentials auprès du contrôleur de domaine. (6) Avant de faire la vérification une connexion SSL est activée (7) La vérification effectuée, le serveur ISA envoie les credentials au serveur Exchange

afin de l’authentifier une deuxième fois et valider l’accès à la messagerie. (8) De même que pour les étapes précédentes, avant d’effectuer l’authentification et

valider l’accès, une connexion SSL est activée. (9) Le serveur Exchange publie son site web OWA, ou le protocole RPC, par

l’intermédiaire du serveur ISA.

Cette configuration nous donne un aperçu complet du fonctionnement du système. Pour vérifier que les communications se font en SSL, une analyse de trames a été effectuée depuis le serveur ISA. Résultat de l’analyse :

Fig.34 Analyse du trafic avec ISA en interne



� L’encadré noir correspond aux communications entre le client et le serveur ISA

� L’encadré bleu correspond à la validation du login et du mot de passe de

l’utilisateur sur le Catalogue Global Active Directory (protocole LDAP)

� L’encadré rouge correspond à l’authentification de base et l’accès au site OWA.

Les communications entre le client et le serveur ISA sont sécurisées en SSL, de même que les communications entre le serveur ISA et le contrôleur de domaine et entre le serveur ISA et le serveur de messagerie Exchange. La validation de ces tests m’ont permis de commencer l’installation du serveur ISA en DMZ et d’effectuer de nouveaux tests pour vérifier que l’intégration s’est bien passée.

� Tests en DMZ :

La première étape a consisté à configurer le pare-feu afin qu’il autorise l’accès au serveur ISA par internet en HTTPS, puis l’accès au serveur Exchange en HTTPS et le serveur Active Directory en LDAPS.

1er test :

Avant d’ouvrir l’accès depuis internet vers le serveur ISA, j’ai d’abord testé que le serveur communiquait correctement avec les serveurs internes. Pour cela une règle NAT a dû être configurée au niveau du pare-feu :

� Un NAT du LAN vers la DMZ sur le port 443 puis 3269 et un « forward » de toutes les connexions entrantes sur le port 443 puis 3269 de l’interface de la DMZ vers le serveur Exchange sur le port 443 :

Source Destination

NAT IP passerelle LAN IP passerelle DMZ

Forward Forward

IP ISA IP ISA

IP Messagerie IP contrôleur de domaine

Les tests validés, j’ai paramétré une règle NAT permettant l’accès depuis le web au serveur ISA, donc à la messagerie, en utilisant mon identifiant.

2ème test :

Des règles d’accès ont été créées du réseau WAN (internet) vers la DMZ et la règle précédente a été désactivée. L’objectif étant de vérifier que nous pouvons, depuis internet, accéder à la page d’authentification fournie par le serveur ISA. Règles NAT internet > Serveur ISA :

� Configuration d’une règle NAT de la DMZ vers l’extérieur sur le port 443 et d’un « forward » de toutes les connexions entrantes sur le port 443 de l’extérieur vers le serveur ISA web Proxy :



Source Destination

NAT IP passerelle DMZ IP passerelle WAN

Forward IP publique IP ISA

3ème test :

� Test de l’accès au serveur ISA depuis le LAN à partir de l’adresse https://mailhost.panhard.fr/exchange

� Test de depuis l’extérieur � Vérification du trafic avec Microsoft Network Monitor

Fig.35 Schéma de test avec ISA server 2006 en DMZ

Description :

(1) L’utilisateur saisit l’adresse du site https://mailhost.panhard.fr/exchange ou effectue une requête via Outlook

(2) La requête de l’utilisateur est redirigée par le DNS public vers l’adresse publique de la

société (3) Le serveur ISA reçoit la requête et va établir la connexion SSL pour permettre à

l’utilisateur de s’authentifier (4) Lorsque l’utilisateur valide ces informations d’authentifications, le serveur ISA établit

une connexion SSL avec le Contrôleur de domaine, puis il fait une vérification des identifiants et renvoie une réponse au serveur ISA

(5) La vérification effectuée, le serveur ISA établit une connexion SSL avec le serveur de

messagerie. Il envoie les credentials au serveur Exchange afin d’authentifier l’utilisateur auprès du serveur de messagerie et de valider l’accès à la messagerie

(6) La vérification effectuée et les connexions SSL établies, l’utilisateur peut travailler avec

sa boîte de messagerie.



Pour s’assurer que les tunnels de communications SSL étaient bien déployés, une analyse des trames a été effectuée. Analyse du trafic :

Fig.36 Analyse du trafic avec ISA en DMZ

� L’encadré jaune correspond aux communications entre le client et le serveur ISA

� L’encadré rouge correspond à la validation du login et du mot de passe de l’utilisateur sur le Catalogue Global Active Directory (protocole LDAPS)

� L’encadré bleu correspond à l’authentification de base et l’accès au site OWA.



4ème test :

Pour vérifier que l’ouverture du port 443 HTTPS n’engendrait aucune faille, j’ai pu analyser les risques d’intrusions à l’aide d’un logiciel nommé Nessus , utilisé par la plupart des sociétés grâce à son efficacité et le fait qu’il soit freeware. En analysant l’IP publique de la société, afin de déterminer les éventuelles failles, j’ai pu constater que le certificat était détecté en tant que certificat SSLv2 avec un procédé de chiffrement faible. Une solution est donnée dans la partie 1.19 Problèmes rencontrés .

Pour terminer, la page d’authentification fournie par le serveur ISA, a été personnalisée.

Une Notice d’accès au site web OWA a été rédigée (cf. Annexe 2 : Notice d’accès OWA). La notice se devait d’être la plus simple possible. ISA server a la possibilité de générer des rapports journaliers, hebdomadaires et mensuels. Ils ont pour objectif de nous renseigner sur le trafic du serveur ISA. J’ai donc configuré le serveur de façon à ce qu’il génère des rapports journaliers, hebdomadaires et mensuels (cf. Annexe 9 : Rapport ISA server).

1.19 Problèmes rencontrés

Plusieurs problèmes ont été rencontrés :

� Problème de certificat : Avant d’utiliser OpenSSL, une solution Microsoft était utilisée. Elle consistait à créer son autorité de certification, par exemple, sur le serveur de messagerie. Cette autorité permettait de délivrer des certificats, mais le problème s’est posé au moment de l’installation du certificat dans le navigateur. En effet, le certificat généré par l’autorité de certification ne permettait pas d’être reconnu comme fiable par le navigateur, car, comme je l’ai dit précédemment, le navigateur ne peut valider un certificat automatiquement que si l’autorité de certification est reconnue par le navigateur. Il fallait importer le certificat d’autorité (racine ou autorité de certification) sur les postes manuellement, ce qui était assez contraignant.

Solution : La solution fut de passer par OpenSSL, ce qui a permis de créer un certificat intégrant l’autorité de certification, c’est ce que l’on appelle un certificat auto-signé.. Dès la première visite de la page web, il suffit d’installer le certificat pour être considéré comme autorité de confiance.

� Faille de sécurité moyenne :

En analysant l’adresse IP de la société à l’aide de Nessus, un risque moyen au niveau du protocole SSL a été détecté.



Fig.37 Faille de niveau moyen du certificat

Solution : Le problème a été résolu en modifiant le registre du serveur ISA. Par défaut, le serveur utilisait le protocole SSLv2 avec un procédé de chiffrement (cipher) faible (<40bits). Il a donc été nécessaire de désactiver ce protocole, et de laisser le SSLv3 et TLS 1.0 actif et de désactiver tous les procédés de chiffrement inférieurs à 128bits afin d’offrir un niveau élevé de protection.

Fig.38 Résultat de l’analyse du certificat SSL après modification

Le protocole SSLv3 est bien reconnu. Aucun risque n’est détecté et le cipher (procédé de chiffrement) est supérieur à 112 bits.



� Mise à jour du serveur : Pour le moment le serveur ne peut être mis à jour automatiquement, car il est isolé dans la DMZ et aucun serveur DNS n’est présent.

Solution : Le serveur étant composé de deux cartes réseaux, il peut être branché sur le réseau interne. Mais cela implique toutefois l’arrêt des services ISA. Cet arrêt engendre une indisponibilité de la messagerie. Une solution consisterait à intégrer, dans la DMZ, un serveur DNS permettant au serveur ISA de pouvoir se mettre à jour. Ou en utilisant le DNS d’un serveur public en configurant les accès sur le serveur ISA et le pare-feu.



14. Serveur WSUS

1.20 Principe de fonctionnement

Fig.39 WSUS mode simple

(1) Le serveur WSUS se synchronise avec le serveur Microsoft Update à une heure

programmée, par exemple le soir ;

(2) Selon des règles définies par GPO (cf. Annexe 10 : Création d’une règle GPO), les clients font une requête de mises à jour auprès du serveur WSUS ;

(3) Le serveur WSUS envoie les mises à jour aux postes clients Le fonctionnement est très simple. Le plus difficile fut de paramétrer les règles GPO ainsi que le serveur WSUS pour permettre de déployer les mises à jour le plus efficacement possible.

1.21 Interface L’interface se veut très simple et très intuitive.

Fig.40 Interface de l’application WSUS



L’interface est identique à celle de l’application ISA server, à gauche le volet de configuration, au milieu le volet d’affichage et à droite le volet d’action.

1.22 Configuration

Les tâches effectuées furent de :

� Définir un serveur pour l’installation � Définir une heure de synchronisation pour le serveur WSUS � Définir des règles GPO pour le déploiement des mises à jour sur les postes � Définir des groupes d’ordinateurs � Définir des règles d’approbation de mises à jour � Rédiger une procédure d’implémentation et de configuration pour le service.

1ère tâche : Pour définir un serveur d’installation, je me suis simplement appuyé sur la configuration minimum à avoir et, avec mon responsable, nous nous sommes mis d’accord pour installer WSUS sur le serveur Antivirus. 2ème tâche : La synchronisation du serveur avec le site de Windows Update devait se faire à un moment ou l’activité était la moins élevée. La synchronisation du serveur WSUS, avec le serveur Windows Update, a été arrêtée vers 5h du matin. 3ème tâche Des règles GPO ont été créées dans l’Active Directory ce qui permet d’effectuer des modifications à distance des postes utilisateurs. L’objectif fut de paramétrer le système de mise à jour des postes utilisateurs et de les faire pointer vers le serveur WSUS à la place du serveur Microsoft Windows Update. Plusieurs options étaient disponibles. Pour les premiers tests, j’ai choisi de prendre le contrôle total des mises à jour, ce qui veut dire que celles-ci sont téléchargées, puis installées automatiquement sur les postes utilisateurs. 4ème tâche : Au niveau du serveur WSUS, lorsque le déploiement s’effectue, les postes détectés sont automatiquement mis dans un groupe « ordinateurs non attribués ». Afin de faciliter l’administration, de nouveaux groupes ont été définis comme suit :

- 1_Pre-validation - 2_bât1 - 3_bât2 - 5_Windows server 2003 - …

Les postes ont été rattachés à un groupe correspondant à leur bâtiment.



5ème tâche : Les mises à jour téléchargées doivent être approuvées pour qu’elles s’installent sur les postes. Pour tous les groupes, deux types de mises à jour ont été approuvés :

- les mises à jour critiques - les mises à jour sécurités

Les autres mises à jour sont seulement approuvées pour le groupe « Pre_validation » afin de les tester avant le déploiement sur les autres postes. Nous avons eu un cas où la mise à jour d’un service Pack Microsoft Office empêchait l’utilisation d’un outil Office, c’est pour cela que nous avons défini un groupe de postes servant de test (Pre_validation). 6ème tâche : Après avoir mis en place la configuration, une procédure d’installation et d’administration du serveur a été rédigée pour le service informatique. Le serveur est encore actuellement en cours de paramétrages, car certaines complications font que la configuration n’est pas encore optimum.

1.23 Tests

Pour vérifier le bon fonctionnement du déploiement, un nouveau groupe a été créé dans l’Active directory : « WSUS ». Sur ce groupe, j’ai appliqué une règle GPO spécifiant que les ordinateurs devaient télécharger et installer les mises à jour aux environs de 11h. Deux postes desktop et un serveur de test ont été intégrés dans le groupe.Le temps de déploiement est variable. 2h ont été nécessaires pour détecter les trois machines. Les postes détectés par le serveur WSUS ont été intégrés dans des groupes différents :

- Deux postes desktop dans le groupe de « Pre_validation » - Le serveur dans le groupe « Windows Server 2003 ».

Le test a montré que le déploiement se faisait sans problème, mais nécessitait un certain temps, et que la règle GPO était bien prise en compte.

Des rapports renseignant sur l’état des mises à jour et l’état de la synchronisation sont générés tous les jours (cf. Annexe 11 : Rapports de mises à jour WSUS) ainsi que des rapports sur l’état de chaque poste (cf. Annexe 12 : Rapport d’installation des mises à jour sur poste).

1.24 Problèmes rencontrés Plantage de certaines applications suite aux mises à jour : Certaines mises à jour ont engendré des modifications de fichiers et ainsi généré des problèmes d’exécution des applications. Ces problèmes sont survenus suite à la mise à jour de service Pack.



Solution : La solution que j’ai choisie est de déployer ces mises à jour pour un seul groupe de test, en l’occurrence le groupe 1- Pre-Validation et de les redéployer sur les autres groupes après avoir validé les tests. Manque de place pour les mises à jour sur le serveur : Les mises à jour prenant de plus en plus de place au fur et à mesure des synchronisations, le manque de place a commencé à se faire sentir. Solution : Attribution d’un nouvel espace disque.



15. IMF Exchange

1.25 Principe de fonctionnement

La solution est assez simple à mettre en place étant donné qu’elle est fournie en natif sur le serveur Exchange et peut être mise en place dans une topologie simple.

Fig.41 Diagramme Filtre IMF

Cette figure nous montre le fonctionnement du filtre. Nous avons la possibilité de créer une liste d’expéditeurs considérés comme fiables ce qui va permettre d’améliorer le filtrage. Au cas où un message serait bloqué dû à un niveau SCL (Niveau de confiance de SPAM) bas, nous pouvons rajouter l’expéditeur dans la liste des utilisateurs fiables, appelée la liste blanche. La fois suivante le message se verra automatiquement renvoyé au destinataire. IMF se base sur une méthode de probabilité pour définir le SCL d’un message. Pour gérer les SPAM, nous utilisons IMF companion, logiciel libre conçu pour gérer les SPAM (supprimer, autoriser, Nettoyer automatiquement la liste …).



1.26 Configuration

La configuration est extrêmement simple. Il suffit d’activer IMF dans la console de gestion Exchange et de choisir le niveau SCL que l’on souhaite adopter. Plus le niveau SCL sera bas plus le filtrage sera strict. Il faut donc ajuster le niveau de façon à ne pas bloquer les messages valides. Le fait que les deux SCL soient au même niveau veut dire que les messages sont tous archivés, aucun n’est envoyé dans la boite de messagerie de l’utilisateur. Il y a donc un contrôle total des messages.

Fig.42 Configuration du Niveau SCL

Après avoir configuré IMF, j’ai installé le logiciel IMF companion et effectué quelques modifications au niveau du registre afin d’obtenir l’affichage du niveau SCL dans IMF companion.

Fig.43 Affichage SCL IMF companion

A la suite de ces différentes configurations, des tests ont été réalisés pour définir la bonne configuration.

1.27 Tests

1er test : Pour les premiers tests, le niveau SCL a été défini à 7.



Fig.44 Console de performance IMF

L’analyse des performances montre que le nombre de messages du niveau SCL 0 au SCL 1 est important, tandis que les messages ayant un SCL supérieur l’est beaucoup moins. Après m’être renseigné auprès de certains utilisateurs pour m’informer de l’efficacité du filtre, j’ai retenu que certains recevaient encore des SPAM. J’ai donc augmenté le filtrage et choisi le niveau SCL 3. A ce niveau, certains messages valides ont été bloqués. J’ai donc débuté la création d’une liste blanche. 2ème test : Après avoir testé le niveau SCL 4 en vue des performances et du nombre de messages ayant un niveau SCL 3, le niveau de filtrage à été diminué à 3.

Le test s’est vu positif, il y a tout de même quelques faux positifs (messages bloqués alors qu’ils sont valides), mais cela a pu être corrigé en ajoutant les expéditeurs en liste blanche. Pour faciliter la réinstallation et l’administration d’IMF, j’ai rédigé une procédure pour le service (cf. Annexe 13 : Procédure d’installation et d’administration d’IMF).

1.28 Problèmes rencontrés Redirection des messages valides : Pour les expéditeurs placés en liste blanche, leurs messages n’étaient pas redirigés automatiquement dans leur boîte mail, mais restaient bloqués. Solution : En cherchant dans la configuration du logiciel, le problème a pu être résolu en choisissant l’option automatique et non manuelle pour renvoyer les messages. Temps de réémission des messages longs : Certains messages dont les expéditeurs sont en liste blanche, mettent de 5mn à 2h pour être réceptionnés par le destinataire. Solution : à ce jour, aucune solution n’a encore été définie. Le problème doit venir du logiciel de gestion IMF companion. Un test devra être effectué avec IMF manager, un équivalent d’IMF companion.



Conclusion technique et perspectives

� ISA server :

Concernant la mise en place du serveur ISA, la tâche a été réalisée avec succès.

Actuellement, trente neuf utilisateurs sont habilités à utiliser Outlook Web Access ou à avoir un accès via le client Outlook et sont satisfaits du fonctionnement, particulièrement ceux étant dotés d’un client Outlook (aucun changement au niveau de l’utilisation). Le serveur est encore une version d’évaluation, mais une version complète est en cours d’achat. Il reste encore des clients Outlook à configurer et aussi de concevoir une solution permettant au serveur ISA de se mettre à jour sans contraintes. L’objectif des 40 personnes ayant l’accès à la messagerie depuis internet n’est pas encore atteint, mais par rapport au délai défini, il reste encore un mois. Pour terminer, je dois finaliser la procédure d’installation et d’administration pour le serveur.

Concernant les perspectives, nous envisageons d’acheter un certificat commercial pour

les transactions SSL. En prenant contact avec un commercial d’une société d’autorité de certification, j’ai pu avoir quelques éclaircissements sur l’avantage d’avoir un certificat commercial. Dans notre cas, nous avons vu que nous pouvions, sur le serveur de messagerie et le serveur ISA, forcer le cryptage à 128bits. Ce qui veut dire que les communications entre ces deux serveurs sont automatiquement cryptées à 128bits. Mais, pour la communication client-serveur ISA, le cryptage à 128bits n’est pas assuré, car coté client nous ne pouvons pas contrôler le niveau de cryptage (il varie selon les systèmes d’exploitations et les navigateurs). Certaines autorités nous permettent de résoudre ce problème en fournissant des certificats utilisant la technologie SGC (ex : Verisign, GlobalSign, Thawte …). Par ailleurs, ce type de certificat est automatiquement reconnu par les navigateurs actuels, donc, pour l’utilisateur, tout devient transparent (pas d’installation de certificat). Avec un certificat commercial, on minimise les temps passés à configurer les postes, car il n’y a plus de certificat à installer. Le niveau de cryptage des données est assuré à 128bits. Le certificat est validé auprès de l’autorité de certification (vérification du nom de la société, vérification du nom de domaine, …) afin d’assurer à l’utilisateur la bonne provenance du certificat. Pour le moment, je dois dresser un tableau comparatif des offres de différentes sociétés de certification afin d’effectuer un choix judicieux en phase avec le niveau de sécurité que l’on souhaite appliquer.

La seconde perspective concerne la publication du serveur de messagerie sur des appareils mobiles tels que les PDA, et de publier l’accès au portail SharePoint.

La dernière perspective serait d’installer le serveur ISA, non plus en DMZ, mais en tant

que second pare-feu. Il offrirait ainsi, un niveau de sécurité élevé pour la société et permettrait, en plus, d’offrir de nouvelles fonctionnalités comme la publication de serveur FTP que nous ne pouvions réaliser en étant en mode carte réseau unique.



� Filtrage IMF :

Concernant le filtrage des SPAM, la solution actuelle répond aux attentes. En

prenant exemple dans le service informatique, aucun SPAM n’a été relevé dans les boîtes aux lettres depuis la mise en place du filtre. Les utilisateurs que j’ai rencontrés sont satisfaits. Concernant l’objectif des 90% des messages filtrés, il a été atteint, puisqu’en moyenne, sur 10 messages par jour, les utilisateurs en reçoivent 1 à 2 par semaine, ce qui nous donne un taux de filtrage de 98%. Cette performance est dûe à un filtrage strict au niveau du Filtre (SCL 3) et une maintenance quotidienne (Mise à jour de la liste blanche). Le résultat est donc plus que satisfaisant.

Pour les perspectives, je vais devoir faire un comparatif des solutions de type

Appliance et comparer la différence de coût entre la solution actuelle et une solution payante. En effet la solution actuelle demande beaucoup de ressources humaines.

� WSUS :

Pour la solution WSUS, il est encore nécessaire d’améliorer la distribution des mises

à jour. Je dois rédiger une procédure d’installation et d’administration. Tous les postes de la société utilisent le serveur WSUS pour se mettre à jour depuis le mois de mai.

Pour les mois à venir, je vais travailler sur la mise en place d’une solution Wifi sur le

site de Marolles en Hurepoix ainsi que sur le site de Saint Germain Laval. Du matériel Wifi sur le site de Saint Germain Laval est déjà à disposition. L’objectif est de sécuriser l’accès à ce réseau. Mon étude va se baser sur le protocole RADIUS, IAS et PEAP/TLS.

Il faudra aussi prévoir la formation de l’équipe aux différents systèmes qui ont été mis

en place.



Conclusion

Actuellement, trois des quatre projets sont opérationnels. Ces projets n’ont pas seulement pour objectif d’offrir aux utilisateurs ou aux administrateurs de nouvelles applications, mais permettent aussi de prouver la qualité, les performances et l’ouverture dont fait preuve le service informatique. Ces projets m’ont permis d’acquérir des compétences dans le domaine de l’administration systèmes et réseaux (Virtualisation VMWARE ESX, cryptologie, pare-feu applicatif, Administration système Windows Serveur, Exchange, …). Confirmant mon souhait de poursuivre mon parcours professionnel dans ce domaine. Ma formation en systèmes embarqués ne me prédestinait pas forcément à ce genre de travail, mais m’a enseigné une certaine méthodologie dans mes recherches, dans la gestion d’un projet et une bonne approche globale sur l’étude de nouveaux outils. Ces travaux m’ont montré l’importance de la sécurité au sein d’un réseau d’entreprise ainsi que les répercussions des améliorations du réseau sur la productivité. De plus, le relationnel et l’organisation contribuèrent à la bonne réalisation des projets. Ce stage m’a amené à concevoir le travail de l’ingénieur dans le cadre de projets informatiques : à savoir qu’il ne faut pas uniquement se contenter de mettre en place des solutions informatiques, mais il est absolument indispensable de réfléchir, dès le commencement du projet, sur la manière dont va être déployé le produit, et de penser à l’accompagnement des utilisateurs pour anticiper les solutions et les réponses à apporter. C’est pour cela que la mise en place de procédures, pour le personnel, et de notices, pour les utilisateurs, sont très importantes pour améliorer la qualité du service informatique.



ANNEXES

ANNEXE 1 « Planning »



Partie1 :



Partie 2 :



ANNEXE 2 « Notice d’accès OWA »

(Concerne l’utilisateur)



Attention :

Avant d’effectuer des manipulations sur Outlook Web access vous devez prendre en considération les Règles à

respecter (3. Règles à respecter) sous peine d’être tenu responsable pour tout incident dû à une négligence de ces

informations.

1. Authentification

Pour accéder à OWA vous devez saisir l’adresse suivante dans votre navigateur :

Les informations d’authentification sont celles que vous utilisez pour vous connecter sur vos postes de travail.

Pour vous authentifier vous devez :

- Saisir votre login précédé du nom de domaine

« PANHARD\ ».

- Saisir votre mot de passe.

Plusieurs Options sont disponibles :

:

A utiliser depuis un lieu public ou privé.

- La session se ferme au bout d’un temps

d’inactivité de 5mn,

- Le login n’est pas stocké en mémoire,

- Les pièces jointes sont bloquées.

: A ne pas utiliser

depuis un ordinateur public (voir 3. Règles à

respecter).

- La session se ferme au bout d’un temps

d’inactivité de 30mn,

- Le login est stocké en mémoire, vous n’aurez

plus qu’à saisir votre mot de passe.

- Les pièces jointes sont accessibles.

:

- Permet d’avoir une version allégée du client OWA.

-

https://mailhost.panhard.fr/exchange



Remarque : Sur des navigateurs autre qu’Internet Explorer, la version allégée sera automatiquement activé.

2. Déconnexion

3. Règles à respecter

1. Vous ne devez pas divulguer vos informations d’authentification.

2. Vous devez vous déconnecter en fermant la fenêtre de navigation ou en cliquant sur Déconnexion du site

web OWA (2. Déconnexion du serveur).

Risques : La session reste ouverte, l’accès à votre messagerie est donc possible.

3. Vous ne devez pas ouvrir de fichiers joints depuis un lieu public. Utilisez l’option « Il s’agit d’un ordinateur

public ».

Risques : Récupération des pièces jointes depuis la mémoire cache du navigateur.

4. Questions/réponses

1. Je n’arrive pas à m’authentifier ?

- Vérifiez que vous utilisez bien le login et mot de passe de votre compte entreprise.

- Vous n’avez peut être pas les droits nécessaires.

- Vérifiez que vous êtes dans une plage horaire à laquelle vous pouvez vous connecter.

2. Je me suis connecté depuis un lieu public en activant l’option « Il s’agit d’un ordinateur privé », et j’ai

ouvert une pièce jointe, comment dois-je faire pour supprimer le fichier de la mémoire cache du navigateur

?

Suivre la procédure suivante pour effacer toutes traces de la mémoire cache du navigateur :

Navigateur Internet Explorer 6 :

- Outils > Options Internet,

- Dans l’onglet Général > Fichiers Internet temporaires cliquez sur Supprimer les fichiers.

Navigateur Internet Explorer 7 :

- Outils > Options Internet,

- Dans l’onglet Général > Historique de navigation, choisissez Supprimer puis dans la nouvelel fenêtre

choisissez Supprimer tout.

Navigateur Firefox :



- Outils > Effacer mes traces,

- Puis sélectionnez toutes les options et validez.

3. Un message d’erreur de certificat s’affiche lorsque je suis sous Internet explorer 7 ?

Suivez la procédure suivante :

Cliquez sur

1°) 2°) 3°)

4°) 5°)

Validez ce qui suit, puis redémarrez votre navigateur.



ANNEXE 3 « Accès au serveur de messagerie via Outlook »

(Concerne l’utilisateur)





ANNEXE 4 « Structure d’un certificat x509 »



Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root CA/[email protected] Validity Not Before: Nov 20 05:47:44 2001 GMT Not After : Nov 20 05:47:44 2002 GMT Subject: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=www.sopac.org/[email protected] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:ba:54:2c:ab:88:74:aa:6b:35:a5:a9:c1:d0:5a: 9b:fb:6b:b5:71:bc:ef:d3:ab:15:cc:5b:75:73:36: b8:01:d1:59:3f:c1:88:c0:33:91:04:f1:bf:1a:b4: 7a:c8:39:c2:89:1f:87:0f:91:19:81:09:46:0c:86: 08:d8:75:c4:6f:5a:98:4a:f9:f8:f7:38:24:fc:bd: 94:24:37:ab:f1:1c:d8:91:ee:fb:1b:9f:88:ba:25: da:f6:21:7f:04:32:35:17:3d:36:1c:fb:b7:32:9e: 42:af:77:b6:25:1c:59:69:af:be:00:a1:f8:b0:1a: 6c:14:e2:ae:62:e7:6b:30:e9 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: FE:04:46:ED:A0:15:BE:C1:4B:59:03:F8:2D:0D:ED:2A:E0:ED:F9:2F X509v3 Authority Key Identifier: keyid:E6:12:7C:3D:A1:02:E5:BA:1F:DA:9E:37:BE:E3:45:3E:9B:AE:E5:A6 DirName:/C=FJ/ST=Fiji/L=Suva/O=SOPAC/OU=ICT/CN=SOPAC Root CA/[email protected] serial:00 Signature Algorithm: md5WithRSAEncryption 34:8d:fb:65:0b:85:5b:e2:44:09:f0:55:31:3b:29:2b:f4:fd: aa:5f:db:b8:11:1a:c6:ab:33:67:59:c1:04:de:34:df:08:57: 2e:c6:60:dc:f7:d4:e2:f1:73:97:57:23:50:02:63:fc:78:96: 34:b3:ca:c4:1b:c5:4c:c8:16:69:bb:9c:4a:7e:00:19:48:62: e2:51:ab:3a:fa:fd:88:cd:e0:9d:ef:67:50:da:fe:4b:13:c5: 0c:8c:fc:ad:6e:b5:ee:40:e3:fd:34:10:9f:ad:34:bd:db:06: ed:09:3d:f2:a6:81:22:63:16:dc:ae:33:0c:70:fd:0a:6c:af: bc:5a -----BEGIN CERTIFICATE----- MIIDoTCCAwqgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBiTELMAkGA1UEBhMCRkox DTALBgNVBAgTBEZpamkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQww CgYDVQQLEwNJQ1QxFjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0B CQEWF2FkbWluaXN0cmF0b3JAc29wYWMub3JnMB4XDTAxMTEyMDA1NDc0NFoXDTAy MTEyMDA1NDc0NFowgYkxCzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWppMQ0wCwYD VQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSUNUMRYwFAYDVQQD Ew13d3cuc29wYWMub3JnMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNv cGFjLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAulQsq4h0qms1panB



Le certificat mentionne son émetteur, contient la clef publique de son propriétaire, la période de validité du certificat et une signature pour vérifier qu'il n'a pas été modifié. Le certificat ne contient pas la clef privée qui ne doit jamais être révélée. Ce certificat contient tous les éléments nécessaires pour envoyer un message chiffré à son propriétaire ou pour vérifier un message dont la signature lui est attribuée.

0Fqb+2u1cbzv06sVzFt1cza4AdFZP8GIwDORBPG/GrR6yDnCiR+HD5EZgQlGDIYI 2HXEb1qYSvn49zgk/L2UJDer8RzYke77G5+IuiXa9iF/BDI1Fz02HPu3Mp5Cr3e2 JRxZaa++AKH4sBpsFOKuYudrMOkCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJ YIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1Ud DgQWBBT+BEbtoBW+wUtZA/gtDe0q4O35LzCBtgYDVR0jBIGuMIGrgBTmEnw9oQLl uh/anje+40U+m67lpqGBj6SBjDCBiTELMAkGA1UEBhMCRkoxDTALBgNVBAgTBEZp amkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQwwCgYDVQQLEwNJQ1Qx FjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0BCQEWF2FkbWluaXN0 cmF0b3JAc29wYWMub3JnggEAMA0GCSqGSIb3DQEBBAUAA4GBADSN+2ULhVviRAnw VTE7KSv0/apf27gRGsarM2dZwQTeNN8IVy7GYNz31OLxc5dXI1ACY/x4ljSzysQb xUzIFmm7nEp+ABlIYuJRqzr6/YjN4J3vZ1Da/ksTxQyM/K1ute5A4 /00EJ+tNL3b Bu0JPfKmgSJjFtyuMwxw/Qpsr7xa -----END CERTIFICATE-----



ANNEXE 5 « Création d’un certificat auto-signé »

(Concerne l’administration réseau)



� Installer OpenSSL

� Ouvrir l’invite de commandes

� Aller dans le répertoire c:\OpenSSL\bin

� Créer un répertoire sslcertificat : mkdir sslcert pour isoler votre travail

� Saisir les commandes suivantes :

o Génération d’une clé privée : openssl genrsa -out sslcert/ca.key 1024 (CA est à titre d’exemple)

o Génération d’un certificat autosigné : openssl req -config openssl.cnf -new -x509 -days 1 -key sslcert/ca.key -out sslcert/ca.cer

o Exporter le certificat avec la clé privée au format pkcs12 : openssl pkcs12 -export -inkey sslcert/ca.key -in ss lcert/ca.crt –out mailhost.pfx -name ‘’Publication Web’’

� Le certificat est enregistré dans le répertoire c:\OpenSSL\bin\sslcert au format .PFX



ANNEXE 6 « Configuration OWA »




1. Installer un certificat

Suivre la procédure « OPENSSL – Création d’un certificat » puis exportez le sur le serveur de messagerie.

Suivez les étapes suivantes pour assigner le certificat au site web Outlook Web Access puis activer le SSL :

1°) Une console de gestion des certificats est normalement créée sur le serveur : « CertificatOrdinateurLocal » dans le

menu Démarrer>Outils d’administration.

Si vous avez effectué une installation complète du système, il vous faut créer une nouvelle MMC. Pour cela suivez les

étapes suivantes :

� Démarrer>Exécuter, puis tapez MMC

� Fichier>Ajouter/supprimer un composant logiciel enfichable

� Cliquez sur Ajouter, choisissez Certificats puis cliquez sur Ajouter

� Choisissez Le compte de l’ordinateur puis laissez le reste par défaut.

2°) Après avoir ouvert ou créé la console, vous pouvez procéder à la vérification ou à l’importation des certificats.

� Cas ou une console existe déjà :

o Vérifiez dans les dossiers Personnel>Certificats et Autorités de certification racines de

confiance>Certificats, que les certificats sont présents.

� Cas ou vous venez de créer la console :

o Effectuez un clic droit sur le dossier Personnel, Toutes les tâches>Importer…

o Suivez les instructions

o Saisissez le mot de passe que vous avez utilisé lors de l’exportation, puis cliquez sur Terminer

o Pour finir vous devez copier les certificats dans le dossier Autorités de certification racines de

confiance en effectuant un copier-coller

2. Forcer le SSL

� Ouvrir la console IIS, Démarrer>Outil d’administration>Internet Information Security

Les répertoires sur lesquels le SSL doit être forcé sont : /Exchange, /Exchweb, /Public, /RPC



� Sous le nœud Site Web par défaut, effectuez un clic droit sur le dossier

Exchange

� Cliquez sur l’onglet sécurité de répertoire

� Dans Communications sécurisées, cliquez sur

Modifier

� Cochez les options suivantes :

� Effectuez la même manipulation sur les deux autres répertoires

3. Authentification

L’authentification de base doit être activé pour les répertoires virtuels /Exchange, /Public.

� Effectuez un clic droit sur le dossier virtuel

� Cliquez sur Propriétés

� Cliquez sur l’onglet Sécurité de répertoire

� Cliquez sur Modifier

� Choisissez les paramètres suivants :



ANNEXE 7 « Configuration du serveur ISA »




1. Installation

� Exécutez le fichier isaautorun.exe puis choisissez Installer ISA Server 2006

� Ajoutez des plages réseau en sélectionnant votre carte réseau, puis cliquez sur suivant

� Décochez, dans la fenêtre qui suit, l’option suivante :



� L’installation va débuter, vous trouverez la console de gestion ISA Server dans le menu

Démarrer>Programmes>Microsoft ISA Server

2. Configuration publication OWA

a. Importation des certificats Les certificats suivant : « DC1.domaine.fr » (Contrôleur de domaine) et « mailhost.panhard.fr » (serveur de messagerie), doivent être présent sur le serveur ISA. 1°) Une console de gestion des certificats est normalement créée sur le serveur : « CertificatOrdinateurLocal » dans le menu Démarrer>Outils d’administration . Si vous avez effectué une installation complète du système, il vous faut créer une nouvelle MMC. Pour cela suivez les étapes suivantes :

� Démarrer>Exécuter, puis tapez MMC � Fichier>Ajouter/supprimer un composant logiciel enfichable � Cliquez sur Ajouter , choisissez Certificats puis cliquez sur Ajouter

� Choisissez Le compte de l’ordinateur puis laissez le reste par défaut. 2°) Après avoir ouvert ou créé la console, vous pouvez procéder à la vérification ou à l’importation des certificats.

� Cas ou une console existe déjà : o Vérifiez dans les dossiers Personnel>Certificats et Autorités de certification racines de

confiance>Certificats, que les certificats mailhost.panhard.fr et DC1.domaine.fr .

� Cas ou vous venez de créer la console : o Effectuez un clic droit sur le dossier Personnel , Toutes les tâches>Importer… o Suivez les instructions o Saisissez le mot de passe que vous avez utilisé lors de l’exportation, puis cliquez sur

Terminer o Pour finir vous devez copier les certificats dans le dossier Autorités de certification

racines de confiance en effectuant un copier-coller



b. Configuration réseau

� Sur le volet de la fenêtre de gauche, développez Configuration puis cliquez sur Réseaux � Dans le volet de droite, cliquez sur Modèles puis choisissez la configuration Carte réseau unique

� Suivez les instructions, laissez tout par défaut � Pour finir Appliquez la modification

c. Création d’un port d’écoute SSL

� Dans le volet de gauche cliquez sur Stratégie de pare-feu � Dans le volet de droite, cliquez sur Bte à outils � Développez Objets de réseau � Effectuez un clic droit sur le dossier Port d’écoute web � Choisissez Nouveau port d’écoute Web…

� Choisissez un nom pour la publication

� Choisissez l’option connexion sécurisée

� Sélectionnez le certificat utilisé par le site web OWA : mailhost.panhard.fr

� Choisissez un nom pour la règle :

� Suivez les instructions suivantes :



d. Ajout d’un serveur LDAP

� Dans le volet de droite, développez Configuration puis cliquez sur Général

� Dans Administration ISA Server choisissez Spécifier les serveurs RADIUS et LDAPS

� Cliquez sur Ajouter � Dans la nouvelle fenêtre cliquez sur Ajouter � Saisissez le nom du serveur LDAP (DC1.domaine.fr), puis validez



� Saisissez et cochez les options suivantes puis validez

� Sur la première fenêtre cliquez sur Nouveau � Ajoutez une expression de connexion, celle que les utilisateurs devront utiliser lors de leur connexion � Sélectionnez le serveur LDAP quel s’applique cette expression � Puis cliquez deux fois sur OK

e. Création des groupes utilisateurs

� Dans le volet de gauche, cliquez sur Stratégie de Pare-feu � Dans le volet de droite, cliquez sur Bte à outils puis choisissez utilisateurs � Cliquez sur Nouveau � Donnez un nom de groupe (de préférence donnez le même nom de groupe que ceux créés dans

l’Active directory), puis cliquez sur Suivant



� Cliquez sur Ajouter puis sélectionnez LDAP …

� Dans Groupe de serveurs LDAP , sélectionnez le serveur créé précédemment � Saisissez le nom du groupe que vous avez créé dans l’Active Directory ou le nom de l’utilisateur que

vous souhaitez ajouter

� Cliquez deux fois sur OK

� Terminez l’assistant, puis appliquer les modifications.

f. Création des planifications

� Dans le volet de gauche, cliquez sur Stratégie de Pare-feu

� Dans le volet de droite, cliquez sur Bte à outils puis

choisissez Planifications

� Cliquez sur Nouveau et personnalisez la planification.



g. Création de la règle de publication OWA

� Dans le volet de gauche, cliquez sur Stratégie de Pare-feu � Dans le volet de droite, cliquez sur Tâches puis choisissez Publier l’accès de client Web

Exchange � Suivez les instructions suivantes :



� Ajoutez les groupes qui seront affectés à cette règle

� Appliquez les modifications

� Effectuez un clic droit sur la publication puis sélectionnez Propriétés � Cliquez sur l’onglet trafic et cochez Exiger un cryptage 128bits pour le trafic http

� Cliquez sur l’onglet Paramètres de l’application , sélectionnez les options ci-dessous



� Vous pouvez choisir une planification pour cette règle

Remarque : On ne peut affecter qu’une planification pour une règle d’accès, donc pour gérer des planifications différentes selon les groupes d’utilisateur, il sera nécessaire de créer plusieurs règles.

h. Planification des rapports

Vous avez la possibilité de créer des rapports journaliers, hebdomadaires et mensuels sur l’utilisation du serveur ISA, le trafic web, les protocoles utilisés, …

� Dans le volet de gauche, cliquez sur Surveillance � Dans le volet du milieu, cliquez sur Rapports � Dans le volet de droite, cliquez sur tâches puis Créer et configurer les tâches de rapport � Suivez l’assistant et choisissez vos options

i. Configuration du cache

� Dans le volet gauche, cliquez sur Configuration puis Cache � Dans le volet de droite, cliquez sur Tâches puis choisissez Créer une nouvelle règle de cache



j. Sauvegarde de la configuration

� Laissez le reste par défaut.



k. Configuration RPC sur HTTPS Ce protocole permet d’accéder à la messagerie Exchange avec Outlook via https. Pour configurer cet accès, vous devez avoir configuré le serveur LDAP et le port d’écoute SSL (identique à OWA), pour cela référez vous à la partie précédente.



ANNEXE 8 « Configuration du client Outlook »




Configuration :

Il convient ici de choisir ‘’Se connecter à l’aide de mon réseau local’’ et désactiver ‘’Se connecter à la boite … avec HTTP’’ lorsque l’on est sur le réseau interne bien que cette configuration fonctionne avec ces paramètres en interne, elle utilise la Bande Passante vers internet.



Pour vérifier que la connexion se fait bien en HTTPS taper la commande suivante dans exécuter : outlook /rpcdiag



ANNEXE 9 « Rapport ISA server »












ANNEXE 10 « Création d’une règle GPO »




� Aller dans les propriétés du groupe auquel on souhaite appliquer la règle :

� Créer et donner un nom à la règle :

Il suffit de cliquer sur la règle pour déterminer les choix de configuration. Pour que la règle soit appliquée il faut que les postes cibles soient redémarrés.



ANNEXE 11 « Rapport de mises à jour WSUS »






ANNEXE 12 « Rapport d’installation des mises à jour sur poste »




Vue générale

Vue détaillée



ANNEXE 13 « Procédure d’installation et d’administration d’IMF »




1. Activation du Filtre IMF (Intelligent Message Filter)

� Ouvrir la console de gestion Exchange � Effectuer un clic droit sur Remise des messages et choisir Propriétés puis appliquer la configuration

suivante :

Les messages ayant un contrôle d’accès (SCL : SPAM Confident Level) supérieur à 4 seront automatiquement stocké dans le dossier archive suivant : C:\Program Files\Exchsrvr\Mailroot\vsi 1\UceArchive. La configuration du courrier indésirable de la banque est réglée au même niveau que la configuration du blocage de la passerelle afin de nous laisser un contrôle total sur la gestion des SPAM.



2. IMF companion

a. Installation IMF Companion permet de gérer les messages indésirables : suppression, renvoi, création d’une liste blanche. La liste blanche permet de considérer des expéditeurs qui ont été bloqués par le filtre comme valide.

� Laisser les options d’installations suivantes par défaut.

b. Paramétrages

� Assigner les dossiers de réception de spam « UceArchive » et de renvoi « PickUp »



� Automatiser le renvoi des messages envoyés par les expéditeurs de la liste blanche

c. Utilisation

Après avoir assigné le dossier « UceArchive », les messages situés dans ce dossier, doivent apparaitre dans le volet du haut. Vous pouvez appuyer sur F5 pour actualiser la liste. Présentation générale :

Rouge : Contenu du dossier d’archive « UceArchive ». Affiche tous les messages qui ont été considérés comme SPAM par le filtre IMF Bleu : Informations relatives au message : Expéditeurs ; Destinataires ; Sujet ; corps du message. Vert : Informations sur le contenu du message.



� Barre d’outils

Remarque : Ces options sont disponibles lorsque vous faites un clic droit sur un message.

� Vérifier le niveau SCL

Le niveau est indiqué à droite du volet. Le niveau SCL nous donne le niveau d’importance en tant que SPAM. Plus le niveau est haut (maximum 9) plus le message est considéré comme SPAM.

Documents

Amélioration et Sécurisation du réseau informatique