Вы находитесь на странице: 1из 41

IUT de Béziers

Licence Pro. R&T option ASUR

IUT de Béziers Licence Pro. R&T option ASUR Mise en production d’un serveur mail et monitoring

Mise en production d’un serveur mail et monitoring

Jean Labarussiat

Stage réalisé du 10 décembre 2007 au 25 avril 2008 sous la tutelle de M. Luc Bégault

Table des matières

Introduction

3

1 Etude de l’existant et contexte professionnel

 

4

1.1 L’entreprise

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

5

Le stage

1.2 .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

5

1.3 Organisation du temps

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

6

2 Serveur mail

8

2.1 Présentation de composition logicielle

 

9

2.2 Intérêt(s) et apport(s) pour l’entreprise

 

13

2.3 Réalisation de la solution

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

14

2.4 Migration

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

25

2.5 Problème(s) rencontré(s)

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

25

3 Monitoring

27

3.1 Présentation des logiciels

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

28

3.2 Mise à jour de la plateforme de Béziers

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

31

3.3 Intérêt et apport pour l’entreprise

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

33

3.4 Problème(s) rencontré(s)

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

33

4 Évaluation des résultats et possibilités d’évolution

 

34

4.1 Évaluation des résultats

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

35

4.2 Possibilité d’évolution

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

36

Conclusion

37

Glossaire

38

Bibliographie

39

Résumé

40

 

2

Introduction

Afin de valider l’année de licence professionnelle réseau et télécom option administra- tion et sécurité des réseaux, un stage de 20 semaines est prévu. Le but de celui-ci étant de nous professionnaliser pour faciliter notre entrée dans la vie active.

Je réalise donc mon projet au sein du service ISR (Infrastructure Système et Réseau) de la société do|you|soft TM basée sur Béziers. Celle-ci propose une solution de commerce électronique ainsi que l’hébergement du site web.

Aujourd’hui, cette société orientée vers le e-business communique de différentes façons :

téléphonie, mail et messagerie instantanée entre autres. Par ailleurs, dotée de nombreux serveurs de production sur Paris, Montpellier et Béziers, do|you|soft TM utilise des logiciels de supervision mais avec les évolutions du parc et le travail quotidien prioritaire, ceux-ci sont devenus obsolètes.

C’est pourquoi ma mission est composée de deux parties : finaliser la mise en place d’un serveur mail pop/imap sécurisé puis mettre à jour les lo giciels de monitoring actuels et les schémas correspondants au réseau de manière à avoir un meilleur suivi. Ce projet s’inscrit donc parfaitement dans le cursus choisi.

J’aborderai l’intérêt de mettre en place de tels moyens et ce qu’ils apportent à une société telle que do|you|soft TM , les problèmes que j’ai pu rencontrer tout au long de l’avan- cement du projet et enfin les possibilités d’évolution qu’ils pourraient en résulter.

3

Chapitre 1

Etude de l’existant et contexte professionnel

4

Etude de l’existant et contexte professionnel

L’entreprise

1.1 L’entreprise

La société do|you|soft TM est une SA au capital de 411 390 euros composée d’une équipe de 30 personnes exclusivement dédiée à ses offres loca tives PowerBoutique R . Plus de 200 000 euros par an sont consacrés à la recherche et au déve loppement, sa politique d’innovation a ainsi pu recevoir le soutien de l’ANVAR (Agence Nationale de VAlorisation de la Recherche).

1.1.1 Situation géographique

Elle bénéficie d’une double implantation géographique en Île-de-France et en Languedoc- Roussillon. L’antenne parisienne commercialise la solution e-business PowerBoutique R . Une partie des serveurs de production sont hébergés chez IFR à Paris, les autres se trouvent à Montpellier. Enfin, le centre de recherche et d’administration réseau se situe dans le centre ville de Béziers, c’est aussi le siège social.

1.1.2 Activité

Avec la solution de vente en ligne PowerBoutique R , do|you|soft TM propose à divers acteurs de la scène économique française d’héberger leurs sites web où ils pourront déve- lopper une activité lucrative, non-négligeable aujourd’hui, par le biais d’internet.

1.2 Le stage

1.2.1 Objectifs

Lors du premier contact avec l’entreprise, nous avons discuté de divers projets pouvant être mis en place durant le stage. Le projet qui en est ressorti a donc été dans un premier temps la finalisation et la mise en production d’un serveur de mail pop/imap sécurisé, reposant sur le système d’identification Kerberos. Puis, da ns un second temps, la mise à jour du serveur de monitoring de Béziers, qui est en réalité utilisé afin de réaliser des tests. Ceci, avant d’appliquer d’éventuels changements sur la plateforme supervisant les serveurs de production.

1.2.2 Intégration

Sous la tutelle de M. Luc Bégault , j’ai intégré le service « infrastructure système et réseau ». Il a été mis à ma disposition un poste de travail, sur lequel j’ai installé le sys- tème d’exploitation GNU/Linux Debian, et également un serveur (sous Debian) et deux machines virtuelles gérées par une Debian-Xen.

Debian a l’avantage d’avoir une politique stricte du libre et un service de mise à jour simplifié. Enfin, suivi par une grande communauté, il permet d’avoir des correctifs de sécurité rapidement.

5

Etude de l’existant et contexte professionnel

Organisation du temps

1.3 Organisation du temps

1.3.1 Prévu

6

Etude de l’existant et contexte professionnel

Organisation du temps

1.3.2 Réel

7

Chapitre 2 Serveur mail

8

Serveur mail

Présentation de composition logicielle

Avant toute chose et afin de bien comprendre un projet, établir son cahier des charges est l’une des priorités. C’est ce qui avait été fait par un précédent stagiaire. Toutefois, le système n’étant pas optimal, le cahier des charges a été redéfini. Ainsi, il a fallu rediscuter des contraintes à mettre en place. Il en est ressorti trois ca tégories principales :

1. Contraintes techniques

– paquets Debian maintenus et suivis ;

– gestion des données LDAP ;

– sécurisation (antispam, antivirus, Kerberos5) ;

– gestion des absences.

2. Contraintes financières

– pas de budget.

3. Contraintes spécifiques

– les utilisateurs remplissent eux-mêmes les données relatives à leurs absences ;

– les utilisateurs doivent pouvoir créer eux-mêmes des dossiers partagés pour leurs services ;

– utilisation obligatoire des logiciels libres ;

– tout le travail se fait en double pour que chaque société (g2 ms TM et doyousoft TM ) ait son système de mail physiquement séparé.

Nous avons ainsi ressorti les solutions qui seraient mis en place par la suite.

2.1 Présentation de composition logicielle

2.1.1 MTA : Postfix

Description rapide :

Postfix est un serveur de messagerie électronique sorti en 19 99. C’est un logiciel libre sous licence IBM développé par Wietse Venema et plusieurs co ntributeurs. Il se charge de la livraison de messages électroniques et a été conçu comme une alternative plus rapide, plus facile à administrer et plus sécurisée que l’historique Sendmail.

Fonctionnement :

Le plus grand avantage de Postfix est qu’il délègue chaque éta pe du traitement d’un mail comme le montre son schéma de fonctionnement.

La figure 2.1 représente l’architecture de Postfix. La délivrance d’un mail se compose de deux étapes : la réception en entrée et sa délivrance.

9

Serveur mail

Présentation de composition logicielle

Serveur mail Présentation de composition logicielle Fig. 2.1 – Schéma de traitement d’un mail par Postfix

Fig. 2.1 – Schéma de traitement d’un mail par Postfix

Réception : Dans le cas où le message est posté localement, c’est le processus pickup qui le traitera. Celui-ci procède à une phase d’analyse des courriers (headers) afin de pro- téger le reste du système. S’il provient d’un réseau, le message est traité par un serveur SMTP.

Les messages peuvent être générés par Postfix lui-même ou par un robot afin de préve- nir l’administrateur des erreurs, adresses introuvables, tentatives de violations des règles, problèmes de

C’est ensuite au tour du processus cleanup qui représente la période finale du traite- ment initial d’un message, notamment la vérification de l’en-tête du message, la réécriture d’adresse, le dépôt du message dans la file incoming et avertit le gestionnaire de liste (qmgr = queue manager) de l’arrivée d’un nouveau mail.

Délivrance : Qmgr se charge donc de contacter un agent (local, smtp, lmtp, pipe) chargé de délivrer les messages en lui communiquant des paramètres (localisation du message, nom/adresse de l’émetteur, nom/adresse du destinataire, machine hôte de

Le gestionnaire de liste maintien une liste séparée des cour riers qui ne peuvent être délivrés immédiatement (deferred). Les messages ne pouvant être définitivement délivrés (bounce) génèrent une trace dinformation dans les logs.

Pour le projet, c’est Maildrop qui s’occupera du traitement local. Il utilise le protocole SMTP (port 25) pour l’acheminement distant des messages.

2.1.2 MDA : Dovecot (IMAP)

Description rapide :

Dovecot est un serveur IMAP et POP3, pour les systèmes d’exploitation Unix et dérivés, conçu avec comme but premier la sécurité. Dovecot est distribué en double-licence MIT (Massachusetts Institute of Technology) et GPL version 2.

10

Serveur mail

Présentation de composition logicielle

Dovecot gère les formats de boîte de messagerie mailbox (un seul fichier) et maildir (un fichier par mail, trié dans des dossiers).

Fonctionnement :

Dans ce projet, pour vérifier que Dovecot fonctionne, le mieux est de paramétrer un client thunderbird. Il faut pour cela créer une nouvelle boite mail qui se connectera à l’une des machines virtuelles IMAP. On doit ensuite paramétrer sur le poste client un logiciel pour demander un ticket Kerberos indispensable à l’authentification. C’est pourquoi il faut spécifier à thunderbird d’utiliser le protocole GSSAPI 1 . Une fois ces paramétrages effectués, il suffit de relever son co urrier dans sa boîte IMAP. Lors de la première connexion, on peut observer la création des dossiers par défaut : new, current et temp.

2.1.3 Annuaire : OpenLDAP

Description rapide :

OpenLDAP est une implémentation libre du protocole LDAP développée par The OpenLDAP Project. Elle est publiée sous sa propre licence : O penLDAP Public License. Bien qu’officiellement distribuée uniquement sous forme de code source, on trouve des versions compilées pour GNU/Linux, BSD, AIX, HP-UX, Mac OS X, Solaris, et Microsoft Windows. Les serveurs LDAP sont conçus pour stocker une grande quantité de données mais de faibles volumes et pour accéder en lecture très rapidement à celles-ci grâce au modèle hiérarchique. C’est donc une base de données où l’on retrouve des informations sur les uti- lisateurs telles que, par exemple, leur UID, GID 2 , numéro de téléphone interne, adresse(s)

LDAP Data Interchange Format (LDIF) permet de représenter les données LDAP sous format texte standardisé, il est utilisé pour afficher ou modifier les données de la base. Il a vocation à permettre une lisibilité des données par le commun des mortels.

Fonctionnement :

L’annuaire LDAP de l’entreprise est, quant à lui, basé sur l’organisation (cf. figure 2.2 ).

2.1.4 Webmail : Horde et modules

Horde Le framework Horde est écrit en PHP et fournit les outils nécessaires à une application web tels que les classes pour définir les préférences, la détection de navigateur, le suivi de

1 Voir Glossaire

2 Voir Glossaire

11

Serveur mail

Présentation de composition logicielle

Serveur mail Présentation de composition logicielle Fig. 2.2 – Schéma LDAP basé sur l’organisation

Fig. 2.2 – Schéma LDAP basé sur l’organisation

L’application par elle-même ne fournit aucune fonctionnalité pour l’utilisateur final. C’est une base pour d’autres applications. C’est pourquoi il est nécessaire d’installer des modules supplémentaires qui viendront se greffer à la structure.

IMP Le module IMP (Internet Messaging Program) de Horde est en fa it le plugin qui permet

la gestion des mails. Il s’agit du webmail, lui aussi basé sur PHP, qui offre la plupart des

fonctionnalités qu’un utilisateur attend de son client mail (filtre, gestion de

.).

Vacation Le module Vacation de Horde permet aux utilisateurs de modifier les valeurs de l’an- nuaire LDAP concernant les données d’absence d’un usager (le message à renvoyer, les dates de début et de fin d’absence).

2.1.5 Mailing-list : Sympa

Description rapide :

Sympa est l’acronyme de Système de Multi-Postage Automatique. C’est un gestion- naire de mailing-list écrit en perl doté d’une interface web. Les données sont stockées dans une base de données (MySQL, Oracle, PostgreSQL).

Fonctionnement :

Dans le cas du projet, comme il y a deux machines virtuelles qui se partagent les noms de domaines, il y a deux interfaces de gestion pour ne pas avoi r de redondance avec les noms de liste de g2ms TM et doyousoft TM . En pratique, Sympa intervient quand postfix ne reconnaît pas l’utilisateur. Sympa récupère alors la liste, cherche dans sa base les adresses mails liées et renvoit à Postfix un mail par adresse présente.

12

Serveur mail

Intérêt(s) et apport(s) pour l’entreprise

2.1.6 Gnarwl

C’est un logiciel basé sur un annuaire LDAP permettant l’envoi de réponses automa- tiques. Ainsi, les utilisateurs n’ont pas besoin d’avoir un compte Unix sur le serveur.

2.1.7 Maildrop

Nous avons choisi de remplacer le processus de livraison de Postfix procmail par mail- drop. Postfix peut être configuré pour livrer le courrier à maildrop via l’agent local de livraison. Ceci présente l’intérêt des substitutions d’alias locaux et de l’exploitation des fichiers $HOME/.forward. On peut l’utiliser pour les domaines listés dans mydestination (paramètre de Postfix [§2.3.1 ]) qui n’ont pas de compte système UNIX.

2.1.8 Sécurisation

Kerberos est un protocole d’identification réseau créé au MIT. Kerberos utilise un système de ticket au lieu de mot de passe en clair. Ce principe renforce la sécurité du système et empêche que des personnes non autorisées interceptent les mots de passe des utilisateurs. L’ensemble repose sur des clés secrètes (chiffrement symétrique 3 ).

2.2 Intérêt(s) et apport(s) pour l’entreprise

Un tel système possède des avantages à différents niveaux. Da ns un premier temps, le fait de changer de protocole, en passant du POP à l’IMAP, entraînera une souplesse pour l’administration réseau. Le service ISR pourra désormais faire des sauvegardes plus simplement sans avoir besoin d’aller, au préalable, allumer le poste client puis copier les boîtes mails. Cela pourra donc s’effectuer de manière totalement transparente pour l’uti- lisateur.

D’autant plus que le dossier /home est un montage NFS. Ainsi, chaque membre de la société dispose d’un seul répertoire pour stocker ses documents. Il suffira de monter le /home sur les divers PC qu’ils utilisent pour que chacun puisse retrouver toute son arborescence de stockage.

Par ailleurs, lors de la création d’un nouvel utilisateur da ns l’annuaire LDAP, il y aura un effet boule de neige entraînant la création du dossier Maildir et son paramétrage.

Malgré tout, ce système possède également des inconvénient s. Sa force est également sa faiblesse : en souhaitant différencier la gestion des list es (cf. Sympa) pour les deux domaines ( doyousoft.com et g2ms.com ), celle-ci s’en trouve alourdie.

En clair, ce système apporte une souplesse indéniable au ser vice ISR mais comme tout système, celui-ci possède quelques inconvénients de par sa structure actuelle.

3 Voir Glossaire

13

Serveur mail

Réalisation de la solution

2.3 Réalisation de la solution

Réalisation de la solution 2.3 Réalisation de la solution Fig. 2.3 – Schéma architectural de distribution

Fig. 2.3 – Schéma architectural de distribution de mail

Nous découvrons dans la figure 2.3 l’architecture que va avoir le système de mail. Le serveur de mail en tête délivre les messages aux deux machines virtuelles (ou VM pour virtual machine). Voici deux exemples de fonctionnement :

Exemple 1 : Un mail arrive pour l’utilisateur jlabarussiat@doyousof t.com, le serveur

.). C’est un domaine géré par la VM DYS (=

DoYouSoft TM ), le mail est relayé. La VM établit une connexion avec l’annuaire LDAP, vérifie l’adresse et par l’utilisation d’une autre requête LDAP remplace ’jlabarussiat ’ par ’jean ’ qui possède un /home monté en NFS. Le mail est écrit dans son /home/<user>\ /Maildir/new/

principal l’examine (antispam,

Exemple 2 : Un mail arrive pour l’utilisateur admin@viagra.com, le serveur principal l’examine. L’utilisateur n’est pas reconnu, il est détruit.

Exemple 3 : Un mail arrive pour l’utilisateur dys@doyousoft.com, le serveur princi-

Ce mail est reconnu

pal l’examine. Le mail passe par les modules antispam, comme spam, il est détruit.

14

Serveur mail

Réalisation de la solution

2.3.1 Configuration

Après avoir compris la théorie, passons à la pratique. J’ado pte une démarche organi- sationnelle dans un premier temps.

– analyse de l’existant, ce qui a été fait par l’ancien stagia ire (pour ne pas reproduire les mêmes erreurs) ;

– analyse des besoins (cf. cahier des charges [§ 2 ]) ;

– descriptif des attributs LDAP nécessaires ;

– mise en place basique ;

– sécurisation du serveur ;

– test de fonctionnement ;

– réglage(s) définitif(s).

Par la suite, il faut se plonger dans les fichiers de configurat ion. C’est l’unique façon de le faire de manière précise. Pour la sécurité des connexio ns, on utilise le protocole ssh ainsi que l’authentification par Kerberos.

Pour une mise en place basique, c’est-à-dire l’envoi et la réception des mails, seuls Postfix, Maildrop et Dovecot doivent être configurés.

Configuration de Postfix

Je vais en premier lieu installer le logiciel et les paquets qui lui sont nécessaires :

# aptitude install postfix postfix-ldap maildrop courier-authlib

Une interface pour la pré-installation apparaît. Choisir « site internet » et valider car les serveurs possèdent une adresse IP publique et envoient les mails directement. Donner le nom de la machine (imap.doyousoft.com ou imap.g2ms.com) et valider. Puis laisser le smtp relayhost vide pour l’instant, je reviendrai sur sa configuration plus tard.

postfix-ldap permet d’intégrer la connexion à un annuaire LDAP ;

maildrop permet d’utiliser maildroprc pour la délivrance du courrier plutôt que procmail (par défaut) ;

courier-authlib est une librairie nécessaire au bon fonctionnement de maildrop .

Postfix se configure très simplement grâce à deux fichiers : main.cf et master.cf . Le premier sert pour la configuration générale et le dernier pour paramétrer les processus qui interviennent lors de chaque étape de livraison d’un mail. Je commence par le fichier principal (main.cf ).

Il faut savoir qu’il existe un très grand nombre d’options po ur la configuration de Post- fix. Je vais décrire celles que j’ai utilisé pour son fonctionnement regroupées en catégories.

Conf. générale :

append_dot_mydomain = autorise/refuse l’ajout du nom de domaine défini à tout utilisateur qui l’oublie lors d’un envoi ;

15

Serveur mail

Réalisation de la solution

maximal_queue_lifetime = période pendant laquelle Postfix réessaye de délivrer un mail ;

program_directory = chemin du programme qui gère les mails ;

queue_directory = chemin du programme qui gère la queue.

Conf. unique :

mydomain = sert à déterminer le domaine de la machine pour avoir le FQDN 4 ;

myhostname = sert à déterminer le nom de la machine pour avoir le FQDN ;

myorigin = utilisé pour déterminer le domaine à ajouter ;

mydestination = Pour quels domaines les mails sont acceptés et distribués.

Conf. recherche LDAP :

local_transport = spécifie de quelle façon vont être distribués les mails en lo cal ;

ldaplocal_server_host

ldaplocal_server_port

ldaplocal_search_base = la base LDAP (dc=exemple,dc=com) ;

ldaplocal_scope = mode de recherche dans l’annuaire ;

ldaplocal_query_filter = filtre les résultats par rapport à ce qui est entré ;

ldaplocal_result_attribute = résultat de la recherche.

= adresse FQDN du serveur ;

= son port ;

Conf. des boîtes aux lettres :

home_mailbox = type de boîte mail ;

mailbox_size_limit = taille limite de la boîte aux lettres (0 = pas de limite) ;

recipient_delimiter = Le séparateur par défaut entre noms d’utilisateurs et ex- tensions d’adresse.

Conf. réseau :

relayhost = vers quelle machine doivent être relayés les mails pour l’envoi ;

mynetworks = réseau autorisé pour l’envoi de mails ;

inet_interfaces = les adresses réseau par lesquelles le système de messageri e reçoit les messages ;

mailbox_command = commande qui va délivrer le mail ;

maildrop_destination_recipient_limit = appelle l’agent de livraison pour chaque

X destinataire(s) ;

default_transport = programme qui va sous-traiter l’envoi de mails.

Conf. utilisateur :

alias_database = base des utilisateurs à utiliser et façon de le faire ;

local_recipient_maps = tables de correspondances contenant tous les noms ou adresses des destinataires locaux ;

recipient_canonical_maps = base des utilisateurs à utiliser pour faire la conver- sion d’uid ;

4 Voir Glossaire

16

Serveur mail

Réalisation de la solution

unknown_local_recipient_reject_code = code d’erreur renvoyé pour un utilisa- teur inconnu qui essaye de se servir du Postfix.

Enfin, comme dit précédemment, nous utiliserons le processus maildrop. Ce fichier est le plus simple à configurer puisqu’il s’agit de décommenter la commande inscrite et d’ajouter un « / » en fin de ligne afin d’obtenir ceci :

DEFAULT="$HOME/Maildir/"

Pour pouvoir utiliser le processus maildrop dans Postfix, il faut le définir dans le fichier master.cf :

maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/local/courier/bin/mail drop -w 90 -d ${user}@${nexthop} ${extension} ${recipient} ${user} ${ nexthop} ${sender}

Avec ceci, la configuration de Postfix est complète, nous pouvons passer à celle du MDA : Dovecot.

Configuration de Dovecot

Après avoir fait quelques recherches sur dovecot, il appara ît qu’un problème avec la gestion de données LDAP l’empêche de fonctionner de façon st able en production. C’est pourquoi il est conseillé d’utiliser la version « backport ». Nous allons préalablement installer le paquet debian-keyring comme précédemment avec la commande aptitude . Puis, il est nécessaire d’aller modifier le fichier /etc/apt/sources.list et d’ajouter ces lignes :

# Etch Backports deb http ://www.backports.org/debian etch-backports main

Pour pouvoir utiliser les dépôts 5 backport, mettre à jour la configuration des dépôts est une priorité avec la commande aptitude update puis installer le paquet dovecot en tapant aptitude install -t etch-backport dovecot-imapd . Penser à commenter la ligne de dépôts backport (ajoutée au fichier sources.list ) pour la suite sous peine d’uti- liser ceux-ci lors des prochaines mises à jour et installations.

Dovecot se configure à l’aide de deux fichiers également : dovecot.conf pour la confi- guration générale et dovecot-ldap.conf pour la connexion à l’annuaire LDAP.

L’inconvénient de dovecot est la lourdeur de son fichier de co nfiguration qui inclut la totalité des variables et la définition de chacunes. Seule une dizaine d’options sont néces- saire à une mise en place basique de ce système. Ainsi, on peut retrouver dans l’ordre d’apparition :

– base_dir = chemin où sont stockées les processus à exécuter ;

– protocols = sert à définir les protocoles d’accès aux boîtes mail ;

5 Voir Glossaire

17

Serveur mail

Réalisation de la solution

– listen = définit sur quelle interface réseau écouter ;

– disable_plaintext_auth = autorise le transfert de mot de passe en clair ;

– ssl_cert_file = chemin absolu vers le certificat ;

– ssl_key_file = chemin absolu vers la clé ;

– login_greeting = message affiché lors d’une connexion imap ( telnet par exemple) ;

– mail_location = sert à définir le format de la boîte mail (mai lbox ou maildir) ;

– mmap_disable = requis si les données sont stockées dans un montage NFS ;

– auth_gssapi_hostname = hostname à utiliser pour le GSSAPI ;

– auth_krb5_keytab = fichier .keytab à utiliser pour le mécanisme GSSAPI ;

– mechanism = sert à définir les protocoles d’authentificatio n ;

– passdb ldap = spécifie l’utilisation d’un annuaire LDAP pour les mots de passe, sa valeur : chemin vers le fichier où trouver la configuration de connexion ;

– userdb ldap = spécifie l’utilisation d’un annuaire LDAP pour les utilisateurs, sa valeur : chemin vers le fichier où trouver la configuration de connexion.

Après cette première partie, les données utiles à l’établissement de la connexion avec l’annuaire LDAP se font dans le fichier /etc/dovecot/dovecot-ldap.conf

hosts = définit l’adresse de l’annuaire LDAP ;

ldap_version = définit la version LDAP à utiliser ;

base = base de l’annuaire ;

scope = définit comment est fait une recherche dans l’annuaire ;

user_attrs = mapping de variables concernant l’utilisateur ;

user_filter = requête LDAP concernant l’utilisateur ;

pass_attrs = mapping de variables concernant le mot de passe ;

pass_filter = requête LDAP concernant le mot de passe.

Concernant Dovecot, il est préférable de stocker tous les fichiers de configuration in- utiles dans un autre sous-dossier car ceux-ci peuvent perturber le bon fonctionnement du système.

Réalisation des premiers tests

Une fois ces paramétrages effectués, nous pouvons passer au t est de fonctionnement.

Utilisation de la commande telnet : telnet <hostname> <port >, et des commandes SMTP.

$ telnet imap.doyousoft.com 25

Trying <adresse IP> Connected to imap.doyousoft.com (<adresse IP>). Escape character is ’^]’.

220 imap.doyousoft.com ESMTP Postfix DYS/PW (Debian/GNU)

$ mail from : jlabarussiat@doyousoft.com

250 2.1.0 Ok

$rcpt to : jlabarussiat@doyousoft.com

250 2.1.5 Ok

18

Serveur mail

Réalisation de la solution

$ data

354 End data with <CR><LF>.<CR><LF>

$ Subject : test

$ c’est un test !
$ .

250 2.0.0 Ok : queued as <ID du message>

$ quit

221 2.0.0 Bye

Connection closed by foreign host.

Pour vérifier que le mail a bien été délivré, il est primordial d’aller voir les fichiers de logs où sont reportés tous les problèmes ou changements que l e système reçoit. Ceux qui sont intéressants pour nous sont /var/log/syslog et /var/log/mail.log . Nous remarquons que les messages transmis ont le status sent (envoyé).

Maintenant que les tests de fonctionnement sont faits, nous pouvons passer à l’étape suivante en ajoutant un webmail.

Configuration de Horde

Horde est une base de travail en PHP pour l’ajout de fonctionnalités aussi appelées modules. A do|you|soft TM , nous avons besoin d’un webmail et d’une interface de paramé- trage pour les absences. Par ailleurs, un webmail nécessite l’installation et la configuration d’un serveur web et des différentes librairies PHP indispensables au bon fonctionnement de celui-ci et de ses fonctionnalités.

Pré-requis # aptitude install apache2 php5 php5-cgi php5-mcrypt php5-mysql php5-ldap\ php5-imap libapache2-mod-php5 php-pear php5-dev php5-gd libmagic-dev make\ libgeoip-dev mysql-client

Lors de l’installation du paquet libapache2-mod-php5 , une interface apparaît pour la configuration du paquet lié libc-client où s’affiche la question : « libc-client doit-il être installé sans la gestion de Maildir ? » Il faut bien entendu répondre non puisque l’on utilise ce format.

Ensuite, des modules supplémentaires recommandés pour horde sont nécessaires :

Mise à jour de pear et installation d’extension :

# pear upgrade all

# pear install Mail_Mime Auth_SASL

# pecl install fileinfo lzf json

fileinfo permet d’améliorer la gestion des pièces jointes.

# echo "extension=fileinfo.so" | /usr/bin/tee /etc/php5/conf.d/fileinfo.ini

19

Serveur mail

Réalisation de la solution

lzf permet de réduire la taille des sessions et donc l’occupatio n mémoire du serveur. # echo "extension=lzf.so" | /usr/bin/tee /etc/php5/conf.d/lzf.ini

Après avoir installé tous les paquets nécessaires au bon fonctionnement du web- mail, nous devons créer et paramétrer la base de données qui lui sera attribuée. Les développeurs de horde ont bien fait les choses et il existe des scripts pour divers sys- tèmes de base de données relationnelles (SQL, MySQL, Postgr eSQL, Oracle). Nous uti- lisons le script create.sql que nous pouvons trouver dans la documentation de horde :

/usr/share/doc/horde3/examples/scripts/sql/ . Il est possible d’exécuter cette créa- tion en une seule commande : /usr/share/doc/horde3/examples/scripts/sql\ /create.sql < < mysql -h <serveur hote> -u <nom d’utilisateur> -p puis vali- der, le mot de passe sera demandé, le taper et valider. Il est important de ne pas écrire le mot de passe en clair, sinon il se trouvera dans l’historique des dernières commandes exécutées.

Horde L’installation se fait avec la commande habituelle aptitude install horde3

La configuration de Horde est réalisée à partir d’une interfa ce web. Pour chaque option, une explication est donnée. Mais avant de les faire, il y a quelques permissions à accorder et des modifications à faire. Nous commençons donc par autori ser les requêtes HTTP vers l’adresse du webmail dans le fichier /etc/apache2/sites-available/default pour ajouter ces lignes avant la fermeture de la dernière balise virtualHost :

Alias /horde3 "/usr/share/horde3" <Directory "/usr/share/horde3"> Options FollowSymLinks AllowOverride Limit deny from all allow from <adresse IP du poste qui va configurer le webmail> </Directory>

Ensuite, nous pouvons entrer l’adresse http://imap.doyousoft.com/horde3 et nous obtenons un message d’erreur prévu par défaut : « Horde3 configuration disabled by de- fault because the administration/install wizard gives the whole world too much access to the system. Read /usr/share/doc/horde3/README.Debian.g z on how to allow access. ». Nous devons commenter ou supprimer les deux premières lignes du fichier de configuration de Horde /etc/horde/horde3/conf.php à l’aide d’un double « / » (signe de commentaire en PHP).

Il faut savoir qu’il existe une autre erreur qui apparaît lorsque l’on fait une réins- tallation de horde (même après un aptitude purge ). Par chance, il suffit avec l’expres- sion régulière sed -i ’s#\\##g’ /etc/horde/horde3/conf.php d’enlever les caractères d’échappement présents dans ce fichier car ils sont mal interprétés.

Pour pouvoir finir la configuration de horde, nous devons donner des permissions d’écriture avec la commande chown 750 /etc/horde puis modifier le groupe propriétaire

20

Serveur mail

Réalisation de la solution

de ces fichiers avec la commande chgrp www-data /etc/horde . Notons que c’est le groupe www-data, celui par défaut des utilisateurs internet. Par ailleurs, nous allons dans un premier temps accorder tous les droits (lecture, écriture, exécution) aux utilisateurs se trouvant dans la plage IP définie dans le fichier d’apache2 et ce, pour le fichier de configuration principal avec la commande chmod 777 /etc/horde/horde3/conf.php . Horde stocke par défaut son ancienne configuration dans un fichier portant l’extension .bak, il n’existe pas par défa ut. Pour le créer, la commande touch /etc/horde/horde3/conf.php.bak mais il faut également lui attribuer des droits chmod 777 /etc/horde/horde3/conf.php.bak . Nous pouvons réactualiser la page internet qui mène vers l’interface de Horde et passer à la configuration interne. Celle-ci est intuitive, il suffit d’aller dans Administra- tion/configuration et choisir « Horde (horde) » à gauche pour entrer dans les options de configuration. Nous obtenons un menu de configuration sous fo rme d’onglets.

Onglet general :

Un chemin qui a son importance sous peine de dysfonctionnement.

what path should we set cookies to ? = chemin où se trouve les fichiers de configuration ( /horde3 ). Le chiffre 3 peut être manquant.

Onglet database :

Il s’agit ici de configurer la base de données pour Horde définie plus haut.

– choisir SQL database ;

– mysql -> custom parameters ;

– database = <adresse FQDN du serveur MySQL> ;

– user = <utilisateur pour la base de données> ;

– passwd = <mot de passe de cet utilisateur> ;

– connect = TCP/IP (3306) ;

– db_name = <nom de la base de données>.

Onglet authentication :

Cet onglet est très important car il faut obligatoirement définir au moins un utilisateur- administrateur (grâce à son UID de l’annuaire LDAP) sous peine de ne pouvoir configurer quoi que ce soit d’autre dans horde. Il existe bien sûr le reco urs à la modification en dur du fichier de configuration mais autant le prévoir dès le début.

– admin_user = administrator, jean ;

– backend = IMAP authentication ;

– choisir separate values ;

– serveur de connexion : localhost ;

– le port : 143 ;

– type de connexion : imap/notls.

21

Serveur mail

Réalisation de la solution

Onglet logging :

Nous allons activer le mode DEBUG qui nous facilite le travail en cas de problème en reportant dans un fichier de log /var/log/horde/horde3.log tout ce qui fonctionne et qui ne fonctionne pas.

– level = PEAR_LOG_DEBUG.

Onglet preference systems Nous définissons l’endroit où seront stockées les préférences de chaque utilisateur.

– choisir SQL database ;

– mysql -> custom parameters ;

– database = <adresse FQDN du serveur MySQL> ;

– user = <utilisateur pour la base de données> ;

– passwd = <mot de passe de cet utilisateur> ;

– connect = TCP/IP (3306) ;

– db_name = <nom de la base de donnée>s ;

– table_name = horde_prefs.

Onglet datatree systems :

– choisir SQL database ;

– mysql -> custom parameters ;

– database = <adresse FQDN du serveur MySQL> ;

– user = <utilisateur pour la base de données> ;

– passwd = <mot de passe de cet utilisateur> ;

– connect = TCP/IP (3306) ;

– db_name = <nom de la base de données> ;

– table_data = horde_datatree ;

– table_attributes = horde_datatree_attributes.

La configuration est prête, il ne nous reste plus qu’à valider en cliquant une fois sur Générer la configuration de Horde (bouton disponible en bas de chaque onglet). Cela aura pour effet de nous déconnecter de l’interface. Le fr amework Horde est mainte- nant disponible, pour en faire un webmail, installons IMP (Internet Messaging Program) développé pour Horde.

IMP L’installation du paquet : aptitude install imp4 .

Quelques permissions doivent être données également : chmod 777 /etc/horde/imp4\ /conf.php . La création du fichier qui stocke par défaut l’ancienne configuration dans un fichier portant l’extension .bak : touch /etc/horde/imp4/conf.php.bak avec les droits chmod 777 /etc/horde/imp4/conf.php.bak . Pour le configurer, il faudra se connecter avec l’UID d’un utilisateur qui est adminis- trateur et son mot de passe kerberos. Puis se rendre dans Administration/configuration et choisir dans la partie de droite Courrier (imp) . Nous retrouvons le style de configuration

22

Serveur mail

Réalisation de la solution

en onglet.

Onglet external utilities :

– Dans "Select any applications that should be linked in IMP’s menu" => sélection- ner horde

Onglet mailbox and fetchmail

– Ce sont des options de présentation, on peut cocher les 4 radiobox si l’on veut.

Valider la configuration avec le bouton Générer la configuration de Horde (bou- ton disponible en bas de chaque onglet).

Par ailleurs, deux autres fichiers doivent être modifiés pour qu’IMP fonctionne parfai- tement : /etc/horde/imp4/servers.php et /etc/horde/imp4/trailer.txt qui rajoute à la fin des mails un texte annonçant l’envoi de ceux-ci par le module IMP, il suffit d’ef- facer son contenu. Nous aurions pu y écrire le nom de la sociét é et ses coordonnées mais le chef de service n’a pas retenu cette idée.

Vacation L’installation du paquet : aptitude install sork-vacation-h3 . Puis les commandes habituelles pour tout nouveau module : chmod 777 /etc/horde/vacation3/conf.php , puis touch /etc/horde/vacation3/conf.php.bak avec les droits chmod 777 /etc/horde\ /vacation3/conf.php.bak .

Nous accédons là aussi à l’administration du module par Admi nistration/configuration puis dans le menu de gauche Absences (vacation) pour avoir accès au paramétrage.

– Décocher "Does your vacation setup support configurable email senders (from :

headers) ?" ;

– Dans "the driver to use", choisir "Exim mailer based LDAP driver" ;

– "Hostname where the LDAP server is running on" : <adresse du serveur LDAP> ;

– "Port that the LDAP server is using " : 389 ;

– "LDAP Protocol Version" : LDAPv3 ;

– "Basedn" : <base du domaine> ;

– "Userdn" : <laisser vide> ;

– "The attribute to search for. If it exists it defines the vaca tion message" : vacatio- nInfo ;

– "The attribute which contains the vacation status" : vacat ionActive ;

– "The value of the status attribute if the vacation is enabled" : TRUE ;

– "The value of the status attribute if the vacation is disabled" : FALSE ;

– "The name of the attribute which acts as the RDN for the ldap entry" : uid ;

– "Should we log the user automatically in with the username a nd password he uses to login to Horde ?" : Yes but with everything after the @ stripped from the username ;

– Décocher "Give the user the ability to change which aliases to use ?" ;

– "Method to retrieve aliases" : none.

23

Serveur mail

Réalisation de la solution

Valider la configuration avec le bouton Générer la configuration de Horde comme pour horde et imp.

Sécurisation Par défaut, apache transmet les données des sites via le prot ocole HTTP (port 80) laissant passer en clair celles-ci entre l’interface du sit e et l’utilisateur. Pour cela, il existe une alternative : du HTTP sécurisé ou HTTPS (port 443), encrypté par le protocole SSL. Pour une meilleure gestion, il est conseillé de créer un fichier par site. Dans le cadre du projet, seule la configuration pour horde nous intéresse. No us la stockerons dans le fichier /etc/apache2/sites-available/horde . Activer le site avec la commande # a2ensite /etc/apache2/sites-available/horde . Spécifier au serveur d’écouter les requêtes vers le port 443 avec la commande echo Listen 443 > > /etc/apache2/ports.conf . Une fois mis en place, penser à faire un /etc/init.d/apache2 reload qui aura pour effet de recharger la configuration d’apache.

Par ailleurs, nous devons activer des modules propres à apache pour le fonctionnement SSL et la réécriture d’adresse : # a2enmod ssl puis # a2enmod rewrite

Configuration de Sympa

Comme tous les autres logiciels, l’installer est prioritaire avec aptitude install sympa.

Sympa dispose d’une multitude de fichiers de configuration ma is un seul servira à notre niveau : /etc/sympa/sympa.conf.

log_level = définit un niveau de DEBUG ;

domain = domaine des adresses ;

listmaster = adresse mail des administrateurs ;

lang = définition de la langue de l’interface web ;

create_list = définit qui a le droit de créer des listes (listmaster, public, abon- .) ;

db_type = type de base de données (mysql, oracle,

db_name = nom de la base de données ;

db_host = FQDN du serveur qui héberge la base de données ;

db_user = l’utilisateur qui à accès à la base de données ;

db_passwd = son mot de passe ;

wwsympa_url = URL de l’interface de sympa (par défaut : URL du serveur/wws

.) ;

Un bug reporté à cette adresse http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208203 nous oblige à taper quelques commandes pour faire fonctionner le gestionnaire :

– cd /etc/sympa

– chgrp www-data cookie sympa.conf wwsympa.conf

– chmod 6755 /usr/lib/cgi-bin/sympa/wwsympa.fcgi

– chown sympa.sympa /usr/lib/cgi-bin/sympa/wwsympa.fcg i

Suite à cela, un autre problème survient. Lors de la création d’une liste, celle-ci n’est

pas active car sympa n’a pas les droits de lancer la commande newaliases. La solution est de lui donner les droits ponctuellement lorsqu’il en a besoin avec la commande qui suit :

24

Serveur mail

Migration

chmod +s /usr/lib/sympa/bin/aliaswrapper .

2.4 Migration

Avant l’étape à proprement dite de la migration des MX 6 , je dois passer sur chaque poste client et configurer le client mail choisi par le service technique (thunderbird). Il y

a peu de chose à modifier mais elles sont obligatoires pour que le client gère le GSSAPI. Pour cela, dans l’interface de thunderbird, faire :

– dans le champ de recherche, taper : network.auth.use-gssapi , sélectionner false ;

– une nouvelle recherche pour : network.negotiate.trusted-uris , double-cliquer sur la variable et y inscrire dys1.net,doyousoft.net.

La migration totale n’a pas pu s’effectuer avant la fin du stage pour diverses raisons. La première étant que le serveur ne possède pas encore la gestio n des mailing-list existantes et que les clients de la société les utilisent. Je n’ai pas eu le temps de résoudre tous les problèmes liés à la gestion des listes. La seconde est que je n’ai pas fini de configurer tous les clients mails de chaque poste. Toutes les personnes n’ayant pas besoin d’accéder aux serveurs ne possèdent pas de mot de passe Kerberos. Elles sont donc dans l’impossibilité de relever leurs mails puisque Dovecot nécessite la connexion grâce à un ticket Kerberos.

Pour cela, l’administrateur réseau doit passer sur les post es pour leur installer un paquetage composé d’une pré-configuration du logiciel kerberos for windows couplé avec leash (utilitaire de gestion des tickets).

2.5 Problème(s) rencontré(s)

Comme dans tout projet, des obstacles s’opposent au bon déro ulement de celui-ci. Avant tout, il faut avoir une compréhension théorique et glo bale du système. Savoir

prendre du recul s’avère également utile pour avancer. Il est nécessaire d’élaborer un

« plan d’attaque » étape par étape, en ajoutant de la difficulté progressivement pour ne pas se laisser submerger par les tâches à accomplir.

De nouveaux problèmes auxquels on ne pense pas, avant d’arriver à un certain stade, peuvent apparaître lors de l’avancée du projet. C’est le cas notamment du système de réponse automatique : le service technique a configuré les serveurs qu’il gère pour recevoir des mails lors de problème, mais ces adresses d’envoi ne nécessite pas de réponse, c’est uniquement un mail d’information. Ainsi, la seule parade que l’on ait trouvé est que les ingénieurs et techniciens ne paramètrent jamais leur système d’absence lorsqu’ils sont en congé ou autres.

6 Voir Glossaire

25

Serveur mail

Problème(s) rencontré(s)

Un autre problème que j’ai soulevé vient de l’architecture qu’ils souhaitent avoir. En effet, en souhaitant bien différencier les serveurs imap, il f aut doubler la configuration, l’inconvénient vient surtout du fait d’avoir deux interfaces de gestion des mailing-list. La personne qui va s’occuper de les créer va devoir gérer deux identités. Ce système aurait ga- gné en souplesse s’il avait été possible d’installer Sympa sur le serveur de tête. Il reste cela dit un problème après mon départ, comme expliqué dans les exemples de fonctionnement de l’architecture actuelle, le premier serveur rejette tous les mails dont les utilisateurs ne sont pas reconnus dans l’annuaire LDAP. Les listes n’y figurent pas en tant qu’utilisateur. Mon tuteur a donc créé des entrées dans l’annuaire pour que le serveur de tête accepte de délivrer les listes de diffusions à la machine virtuelle correspondante. Le problème restant, c’est le traitement de ces envois lors de la réception par les VMs, un script en perl existe mais il n’a pas l’air de fonctionner comme on le souhaite.

26

Chapitre 3 Monitoring

27

Monitoring

Présentation des logiciels

3.1 Présentation des logiciels

Tout d’abord, il faut savoir qu’un administrateur utilise le protocole SNMP (Simple Network Management Protocol), protocole simple de gestion de réseau en français, pour gérer les équipements du réseau, superviser et diagnostiquer des problèmes réseaux.

Principe de fonctionnement du protocole SNMP

Ce système de gestion de réseau est basé sur 3 éléments principaux : un superviseur

.)

(plus couramment appelé manager), des nœuds (swith, routeur, composants et des agents.

Le manager va permettre à l’administrateur de superviser/g érer son réseau en exécu- tant des requêtes de management via une console.

Tous les équipements à administrer doivent être équipés d’un agent SNMP. Ce dernier est en fait un serveur qui reste à l’écoute des éventuelles requêtes qui pourraient être envoyées par l’administrateur, et ce, sur le port UDP 161 seulement. L’agent est donc présent pour écouter les requêtes et y répondre, mais il peut également être configuré pour émettre des alertes. Cela permet d’informer l’administrateur réseau qu’il y a un problème sur le débit d’une interface ou bien au niveau de la température d’un CPU, etc. C’est la raison pour laquelle le manager dispose également d’un serveur qui lui, reste à l’écoute sur le port UDP 162 pour les éventuels signaux d’alarme.

L’agent permet la récupération de toutes sortes d’informations concernant les équipe- ments réseau.

Switchs, hubs, routeurs et serveurs sont des exemples d’équipements contenant des objets manageables. Ceux-ci peuvent être des informations matérielles, des paramètres de configuration, des statistiques de performance et autres ob jets qui sont directement liés au comportement en cours de l’équipement en question. Ces ob jets sont classés dans une sorte de base de données arborescente appelée MIB 1 .

Le protocole SNMP assure le dialogue entre le superviseur et les agents afin de re- cueillir les objets souhaités dans la MIB.

L’architecture de gestion du réseau proposée par le protoco le SNMP peut donc être divisée en trois parties :

– les équipements managés (managed devices) sont des éléments du réseau (pont, switch, hub, routeur ou serveur), contenant des objets de gestion (managed objects) pouvant être des informations sur le matériel, des éléments de configuration ou des informations statiques ;

– les agents, c’est-à-dire une application installée sur chaque équipement réseau, qui transmettent au manager les données locales au format SNMP ;

1 Voir Glossaire

28

Monitoring

Présentation des logiciels

– les systèmes de management de réseau (network management systems notés NMS 2 qui représentent la console depuis laquelle l’administrateur peut gérer.

SNMP en pratique

Concrètement, dans le cadre d’un réseau, SNMP est utilisé :

– pour administrer les équipements ;

– pour surveiller le comportement des équipements.

Une requête SNMP est un datagramme UDP habituellement à destination du port 161. Les schémas de sécurité dépendent des versions de SNMP ( v1, v2 ou v3). Dans les versions 1 et 2, une requête SNMP contient un nom appelé « communauté », utilisé comme un mot de passe. Il y a un nom de communauté différent pour obtenir les droits en lecture et pour obtenir les droits en écriture. Un grand nombre de log iciels libres et propriétaires utilisent SNMP pour interroger régulièrement les équipements et produire des graphes rendant compte de l’évolution des réseaux ou des systèmes informatiques (MRTG, Cacti, Nagios, ).

ou des systèmes informatiques (MRTG, Cacti, Nagios, ). Fig. 3.1 – Schéma de fonctionnement du protocole

Fig. 3.1 – Schéma de fonctionnement du protocole SNMP

2 NMS (Network Management Station) : c’est une machine de management d’un réseau.

29

Monitoring

Présentation des logiciels

Comme on peut le voir sur la figure 3.1 , le protocole SNMP définit aussi un concept de trap. Une fois défini, si un certain évènement se produit, comme par exemple le dé- passement d’un seuil, l’agent envoie un paquet UDP à un serveur. Ce processus d’alerte est utilisé dans les cas où il est possible de définir simplement un seuil d’alerte. Les traps SNMP sont envoyés en UDP/162.

3.1.1 Nagios

Nagios TM (anciennement appelé Netsaint) est une application assura nt la surveillance système et réseau. Elle supervise les hôtes et services préa lablement, émettant des alertes lorsque les systèmes ont un problème et lorsqu’ils vont mieux. Il s’agit d’un logiciel libre sous licence GPL.

Nagios TM est un programme qui nécessite des modules, ceux-ci peuvent être détaillés en trois parties :

1. Le moteur de l’application qui organise les tâches à réali ser au niveau de la super- vision ;

2. L’interface web, qui permet d’avoir une vue d’ensemble du système d’information et des éventuelles anomalies ;

3. Les plugins, une centaine de petits programmes que l’on va pouvoir rajouter au besoin pour superviser les ressources et les services dispo nibles sur l’ensemble des ordinateurs ou des éléments réseaux du parc.

Voici ci-dessous une liste des différentes possibilités qui nous sont proposées par Nagios TM :

– Superviser des services réseaux : SMTP, POP3, HTTP, NNTP, ICMP, SNMP, LDAP, etc ;

– Superviser les ressources des serveurs (charge du processeur, occupation du disque dur, utilisation de la mémoire) et ceci sur les systèmes d’exploitation les plus répan- dus ;

– Interface avec le protocole SNMP ;

– La supervision à distance peut utiliser SSH ou un tunnel SSL ;

– Les plugins sont écrits dans les langages de programmation les plus adaptés à leur tâche : scripts shell (Bash, ksh, etc), C++, Perl, Python, Ruby, PHP, C#, etc ;

– La vérification des services se fait en parallèle ;

– Possibilité de définir une hiérarchie dans le réseau pour po uvoir faire la différence entre un serveur en panne et un serveur injoignable ;

– La remontée des alertes est entièrement paramétrable grâce à l’utilisation de plugins (alerte par email, SMS, etc) ;

– Acquittement des alertes par les administrateurs ;

– Gestion des escalades pour les alertes (une alerte non acquittée est envoyée à un groupe différent) ;

– Limitation de la visibilité, les utilisateurs peuvent avo ir un accès limité à quelques éléments ;

– Capacité de gestion des oscillations (nombreux passages d ’un état normal à un état d’erreur dans un temps court) ;

30

Monitoring

Mise à jour de la plateforme de Béziers

– Chaque test renvoie un état particulier :

1. OK (tout va bien)

2. WARNING (le seuil d’alerte est dépassé)

3. CRITICAL (le service a un problème)

4. UNKNOWN (impossible de connaître l’état du service)

3.1.2 Cacti

Cacti est un logiciel de supervision réseau, il est basé sur R RDTool 3 . Son principe de fonctionnement repose sur un serveur web équipé d’une base de données et du langage PHP. Cacti peut-être perçu comme le successeur de MRTG 4 mais également comme l’in- terface d’interprétation et d’utilisation de RRDTool.

Il permet de représenter graphiquement divers statuts de périphériques réseau utilisant

p our avoir par exemple

l’espace disque restant ou bien la mémoire utilisée, la char ge processeur ou le ping d’un élément actif. Les données sont récoltées auprès des différents agents SNMP (ou auprès des scripts locaux) grâce à un script php. Pour de meilleures performances un exécutable, nommé Cactid, peut également effectuer les interrogations.

SNMP ou encore grâce à des scripts (Bash, PHP, Perl, VBs

)

L’intérêt de ce logiciel réside principalement dans son principe de « modèles » (Tem- plates) qui permet de créer de manière générique les graphiques afin de pouvoir les réuti- liser. De façon générale, « tout » est modèle sous Cacti. Cela est avantageux lorsque de nombreuses données identiques doivent être observées, mais cela peut se révéler fastidieux à configurer lorsque les données sont hétérogènes.

Cacti génère les images dynamiquement à l’affichage à partir des fichiers de données RRDTool.

Il est également possible d’effectuer des opérations simples (et des combinaisons d’opé- rations) avec les différentes données grâce une interface gr aphique.

3.2 Mise à jour de la plateforme de Béziers

3.2.1 Nagios

La mise à jour d’un paquet n’est peut-être pas aussi simple que l’on pense, il ne suffit pas de faire un aptitude upgrade . Il faut ici vérifier les données liées à nagios, seront- elles toujours compatibles après la mise-à-jour ? Si non, fa ire en sorte qu’elles le soient.

L’objectif est de passer de la version 2.09 à la version 2.10 sans encombre. Après quelques heures de recherches dans les différents fichiers de configuration pour comprendre le fonctionnement de Nagios TM j’ai effectué la mise-à-jour avec l’utilitaire aptitude , ce n’est pas simplement une commande, c’est un gestionnaire très complet des paquets et

3 Voir Glossaire

4 Voir Glossaire

31

Monitoring

Mise à jour de la plateforme de Béziers

de leurs dépendances. J’ai donc sélectionné les paquets à mettre à jour. C’est essentielle- ment dans la configuration d’apache qu’il faut veiller au maintien des options paramétrées.

3.2.2 Cacti et ses plugins

La mise à jour de Cacti s’est plus ou moins passée comme celle de Nagios TM à la différence que Cacti possédait des modules supplémentaires. J’ai fait des recherches sur la disponibilité de ces derniers, il s’avère que deux ont la même fonctionnalité : avoir une vue rapide de l’état des machines (active, inactive). Après en avoir discuté avec mon tuteur et lui avoir fourni une comparaison de ces modules, nous avons décidé de n’en garder qu’un des deux, à savoir le plugin « Treschold ». J’ai également réinstallé le plugin « NPC » (nagios pour Cacti) qui reprend des données nagios, il est do nc possible de se servir d’une seule interface pour superviser le réseau. Puis le plugin « Weathermap » qui fournit un graphique actualisé toutes les cinq minutes de la charge réseau.

Il faut noter que pour faire fonctionner tous ces plugins, Ca cti a besoin qu’on lui installe un patch Cacti-plugin-architecture à l’aide d’un fichier Cacti-plugin-architecture.diff qu’il faut appliquer avec la commande patch -p1 -N < Cacti-plugin-architecture.diff . Nous devons ensuite éditer le fichier config.php qui se trouve dans /usr/share/Cacti\ /site/include/ et ajouter ces lignes (attention, en langage php, le « ; » détermine la fin d’une commande) :

– $plugins = array() ;

– $plugins[] = ’<nom du plugin>’ ;

Nous avons décidé de bloquer le paquet Cacti pour ne pas avoir a faire ces manipula- tions lors d’une mise à jour du logiciel.

C’est essentiellement de Weathermap dont je me suis occupé par la suite. J’ai donc fait un schéma réseau lisible qui permet en un coup d’oeil, d’avoir une vue globale de la charge réseau. Pour le réaliser, il est indispensable de connaître l’architecture réseau du parc afin de ne pas se tromper dans le sens des connexions. En eff et, on peut observer sur le schéma un traffic d’upload et un traffic de download.

32

Monitoring

Intérêt et apport pour l’entreprise

3.3 Intérêt et apport pour l’entreprise

Ce type d’outils apporte à une société qui possède un parc machine important, l’assu- rance d’un suivi en temps réel de chaque serveur et une réactivité supérieure à la moyenne grâce à la mise en place d’un service d’astreinte et plusieurs bippers. Les techniciens peuvent ainsi intervenir à tout moment qu’ils soient sur le lieu de travail, ou chez eux, au moyen de login et de connexion sécurisé (Kerberos, clé ssh) vers la plateforme en difficulté.

Ils permettens de surveiller, rapporter et alerter les fonctionnements normaux et anor- maux des systèmes informatiques répondant aux préoccupations suivantes :

– Technique : surveillance du réseau, de l’infrastructure et des machines ;

– Applicative : surveillance des applications ;

– Contrat de service : surveillance respect des indicateurs.

Le service technique de do|you|soft TM se concentre sur deux aspects techniques. La supervision système qui porte principalement sur les trois types de ressources système (processeur, mémoire et stockage) ainsi que la supervision réseau qui porte sur la sur- veillance de manière continue de la disponibilité des services en ligne, du fonctionnement, des débits, de la sécurité mais également du contrôle des flux.

Les solutions les plus connues dans ce milieu sont :

– Nagios : logiciel de supervision en temps réel ;

– Oreon : logiciel de supervision basé sur Nagios ;

– MRTG : logiciel de supervision en utilisant des graphes ;

– Cacti : logiciel de supervision permettant de réaliser des statistiques.

3.4 Problème(s) rencontré(s)

La première chose à faire lorsqu’on souhaite utiliser ce genre d’outil spécifique est de se former aux logiciels par différents moyens car ils ont une interface très riche. Internet est l’un d’eux, on y trouve documentations et tutoriaux en grand nombre, lire les fichiers de configuration s’avère également utile pour comprendre en détail leur fonctionnement.

En ce qui concerne les mises à jour, je n’ai pas eu de problème en particulier. L’utili- taire aptitude est très bien conçu même si l’interface peut paraître déroutante au premier abord.

33

Chapitre 4

Évaluation des résultats et possibilités d’évolution

34

Évaluation des résultats et possibilités d’évolution

Évaluation des résultats

4.1 Évaluation des résultats

4.1.1 A - serveur mail mis en place

J’ai mis un certain temps pour faire les recherches nécessaires à la réalisation de la configuration du serveur et à la compréhension globale du fonctionnement. Ainsi, dû à mon manque de méthodologie, il reste quelques points particuliers que je n’ai pas eu le temps de traiter. C’est notamment le cas de la gestion des listes. Le logiciel fonctionne parfaitement dans la configuration actuelle tant que les adr esses de liste arrivent directe- ment sur les VMs mais ce n’est pas le cas quand elles passent pa r le serveur de tête. Il existe un recours à cette situation mais je ne l’ai pas mis en place. C’est ce dont je devais m’occuper le dernier jour.

Ce qui m’a empêché de le faire est une mauvaise manipulation de ma part. J’ai fait plusieurs scripts pour faciliter mes tâches lors du paramétrage du serveur. J’ai prévu un script de sauvegarde qui récupère tous les fichiers de configuration de chaque logiciel mis en place. Désireux de faire de mon mieux, j’ai effacé les anciennes sauvegardes pour laisser une base propre mais un peu trop propre car j’ai mal tapé ma commande et cela a eu pour conséquence d’effacer le /etc. Impossible de faire marche arrière, mon tuteur a recréé la VM. Heureusement j’avais transféré les anciennes sauvegar des sur mon poste de travail. Il m’a fallu deux heures pour remettre en état le serveur de mail avec le tutoriel que j’avais préparé pour la personne qui devrait maintenir le système après mon départ. J’ai donc pu constater que celui-ci était complet mais pouvait être amélioré.

4.1.2 B - monitoring en production

La carte de la charge réseau fonctionne bien, le problème vient du fait de devoir ré- installer le plugin « architecture » et reconfigurer le fichier d’apparition des modules à chaque mise à jour de Cacti. C’est pourquoi le paquet Cacti a été bloqué pour ne pas se mettre à jour automatiquement mais uniquement lorsqu’on lui demande. L’inconvénient de cette méthode réside dans une mise à jour critique à laquelle nous ne nous attendons pas. Une veille de ce genre d’alerte peut vite devenir encombrante dans le travail quotidien mais cela fait partie intégrante de notre spécialisation en sécurité.

35

Évaluation des résultats et possibilités d’évolution

Possibilité d’évolution

4.2 Possibilité d’évolution

4.2.1 A - Serveur mail

Je pense qu’il est possible de faire encore évoluer le système de mail mis en place. Dans un premier temps, pour le faire gagner en souplesse, il serait bon de repenser le système de gestion de listes actuel. Il serait envisageable de redéfinir le fontionnement du serveur frontal pour que les mails à destination d’une liste soit interceptés et traités en amont. Par ailleurs, la personne en charge des listes n’aura it plus deux interfaces à gérer mais bien une seule. Le problème qui apparaîtra sera celui des noms de liste qui peuvent être en double pour les domaines doyousoft.com et g2ms.com .

Dans un deuxième temps et selon les besoins des utilisateurs, envisager l’évolution du webmail vers un groupware plus abouti, ce que horde permet de faire grâce à l’ajout de modules déjà prévus à cet usage. Et pourquoi pas à terme, se pa sser de clients de messa- gerie tels Microsoft Outlook, Thunderbird ou autre.

4.2.2 B - Monitoring

Au niveau de weathermap, je pense qu’il pourrait être intéressant de posséder deux cartes différentes. Le plan actuel resterait essentiel pour une vue rapide de la situation du réseau. Une deuxième carte avec un ajustement des valeurs de charge pour les liaisons entre le LAN et les serveurs internes afin d’avoir une vue détaillée du traffic réseau ne serait pas de trop.

36

Conclusion

En conclusion, le projet que m’a confié la société DoYouSoft TM est globalement une réussite. Mon projet était en corrélation avec celui d’un autre stagiaire et le travail de l’administrateur réseau. Le service de mail a été mis en production un mois avant la fin du stage en ce qui concerne la transmission des fax par mail. L e système est stable, pas ou peu de problème apparent. A noté cependant qu’il m’a fallu plusieurs semaines de recherche avant de fournir un travail correct mais maintenant et en cas de défaillance mat érielle, celui-ci peut être ré- installé dans l’heure.

Par ailleurs, ce stage m’a été très bénéfique à plusieurs niveaux :

Sur le plan professionnel, j’ai pu avoir une vision de notre métier plus ancrée dans la réalité. J’ai découvert plus en détail différents protocoles tels que LDAP, SMTP, IMAP. J’ai pu voir aussi que l’employeur attend de nous une certaine autonomie et savoir rendre compte du travail effectué est un plus pour le fonctionnement du service.

Sur le plan personnel, j’ai pris conscience de mes difficultés : manque d’organisation, mauvaise approche des problèmes. Je sais donc maintenant quels sont les points qu’il faut que j’améliore.

37

Glossaire

UID/GID : des identifiants que l’on retrouve dans tous les systèmes informatiques per- mettant aux utilisateurs d’accéder à telle ou telle ressource du système.

Chiffrement symétrique : la cryptographie symétrique également dite à clé secrète (par opposition à la cryptographie à clé publique), est la plus ancienne forme de chiffre- ment. L’un des concepts fondamentaux de la cryptographie symétrique est la clé, qui est une information devant permettre de chiffrer et de déchiffrer un message et sur laquelle peut reposer toute la sécurité de la communication.

Dépôts : un dépôt ou référentiel (de l’anglais repository), est un stockage centralisé et organisé de données. Ce peut être une ou plusieurs bases de do nnées où les fichiers sont lo- calisés en vue de leur distribution sur le réseau, ou bien un endroit directement accessible aux utilisateurs. La plupart des distributions Linux utilisent des dépôts accessibles sur Internet, officiels et non-officiels, permettant aux utilisateurs de télécharger et de mettre à jour des logiciels compatibles.

MX (Mail eXchange) : dans la configuration d’un serveur DNS, cette entrée correspond au serveur de gestion du courrier. Lorsqu’un utilisateur envoie un courrier électronique à une adresse (utilisateur@domaine), le serveur de courrier sortant interroge le serveur de nom ayant autorité sur le domaine afin d’obtenir l’enregistrement MX. Il peut exister plusieurs MX par domaine, afin de fournir une redondance en ca s de panne du serveur de messagerie principal. Ainsi l’enregistrement MX permet de définir une priorité avec une valeur pouvant aller de 0 à 65 535.

GSSAPI : est l’acronyme de Generic Security Services Application Program Interface (ou GSS-API), il s’agit d’une application pour autoriser des logiciels à accéder à des ser- vices de sécurité.

MIB (Management Information Base) : est un ensemble d’informat ions structurées sur une entité réseau, par exemple un routeur ou un commutateur. Ces informations peuvent être récupérées, ou parfois modifiées, par un protocole comme SNMP.

RRDTool : c’est un outil de gestion de base de données RRD (Round-Robi n Database) créé par Tobi Oetiker. C’est le standard de l’industrie OpenSource permettant la sau- vegarde et le tracé de graphiques, de données chronologiques. Cet outil a été créé pour superviser des données serveur, telles que la bande passante, la température d’un proces- seur Le principal avantage d’une base RRD est sa taille fixe.

38

Bibliographie

[1] do|you|soft : http://www.doyousoft.com [2] powerboutique : http://www.powerboutique.com [3] Postfix : http://www.postfix.org [4] Dovecot : http://www.dovecot.org [5] OpenLDAP : http://www.openldap.org [6] Sympa : http://www.sympa.org [7] Horde : http://www.horde.org [8] Wikipédia : http://www.wikipédia.com [9] CommentCaMarche : http://www.commentcamarche.net [10] Forum R&T béziers

[11] Dent Kyle, Postfix, La référence . Paris, O’Reilly c , 2004, 244 p. [12] Carter Gerald, LDAP, administration système . Paris, O’Reilly c , 2003, 296 p.

[13] GNU Linux France magazine [14] MISC

39

Résumé

Afin de valider l’année de licence professionnele R&T, un sta ge de vingt semaines est prévu. C’est pourquoi je me suis adressé à la société do|you|soft TM qui commercialise la solution e-business powerboutique R , leader du marché dans son domaine. Celle-ci utilise divers moyens de communication tels que la téléphonie, la messagerie instantanée ou en- core les e-mails.

Ainsi, le projet principal qu’il m’a été demandé de réaliser par do|you|soft TM est l’in- ternalisation d’une architecture de mail sécurisé. Celle- ci est un peu spéciale, à savoir qu’il y a un serveur frontal relié à deux machines virtuelles (VM) qui elles-mêmes gèrent trois domaines différents (doyousoft.com, powerboutique.com et g2ms.com). Le premier serveur va servir à analyser les mails entrants (spam, virus) et les rediriger vers la VM qui s’occupera de les distribuer via Postfix et Maildrop dans les boîtes mails et sont accessibles via IMAP grâce à Dovecot. Les webmails Horde qui sont installés sur les machines vir- tuelles permettent aux personnes qui le souhaitent de consulter leur mail de n’importe où.

En parrallèle, je dois mettre à jour le système de supervisio n de la plateforme de Béziers. Les logiciels utilisés sont Nagios et Cacti. J’ai i nstallé un patch spécial pour ce dernier de manière à pouvoir intégrer des plugins (treshold, npc et weathermap). J’ai sur- tout travaillé sur le plugin weathermap qui permet d’avoir une vue – réactualisée toutes les cinq minutes – de la charge du réseau via les données collectées par SNMP et Rrdtools.

Au final, le projet de mail fonctionne bien mis à part la gestio n des mailing-list où il y a encore des problèmes. Je n’ai donc pas terminé le projet que l’on m’a confié.

40

Abstract

To valid my three years course on network and telecom, I have to do a training period of twenty weeks. So, that is the reason why I solicited the do|you|soft TM society which sold the powerboutique R e-business solution, leader on her domain. Employees use ma ny method to communicate with the world : telephony, instant messenger, fax or e-mails.

Then, my first project for do|you|soft TM is to mount a secured mail server. It has a special architecture with a front server relied to two virtual machines (VM) which distrib three differents domains (doyousoft.com, powerboutique.com and g2ms.com). The front server is used to analyse incoming mails (spam, virus) and redirect to VMs which distrib it to the mailboxes by IMAP protocol. Horde webmail which are installed on the VMs is used by the users who want consult mail everywhere they are.

In second time, I must update supervision system of the Beziers platform. Softwares which are used are Nagios and Cacti. I’ve installed a special patch to integrate plugins (treschold, npc and weathermap). I’ve only worked on the wea thermap plugin which per- mit to have a view – refresh all the five minutes – of the traffic lo ad with the datas collected by SNMP protocol and rrdtools.

In conclusion, I haven’t finish my project but what I do runs well except the mailing-list management.