CAHIER DES CHARGES Projet Supervision

Transcription

1 Master 1 Informatique Année universitaire 2008/2009 CAHIER DES CHARGES Projet Supervision Tuteur : Maxime Charpenne Etudiants :

2 Sommaire Introduction... 3 I - Présentation du projet Intitulé Intérêts et contraintes du projet Contexte... 5 II - Etude de l existant Architecture du système informatique Système Mail de l université d Avignon... 7 III - Expression des besoins Climatisation Mail Samba Apache DNS MySQL IV - Planning prévisionnel Planning du premier semestre Planning prévisionnel du second semestre Conclusion Page 2

3 Introduction L'infrastructure réseau fait aujourd'hui partie intégrante des entreprises, c est pourquoi il est important de mettre en place une surveillance constante de l activité du système d information. L utilisation d outils de surveillance et de scripts d automatisation de tâches permet d optimiser la gestion et le contrôle du système pour les administrateurs, en analysant les événements de l activité du système informatique et en remontant des alarmes lorsque cellesci sont graves. Ainsi lors d une détection d'un problème, l'administrateur sera plus réactif dans sa résolution. Dans le cadre de notre année de Master 1, il nous est demandé de réaliser un projet. Plutôt attirés par l administration des systèmes et des réseaux informatiques, nous avons donc choisi le projet Supervision, en effet celui-ci devrait nous permettre d'acquérir de nouvelles connaissances, d approfondir celles acquises durant les précédentes formations mais aussi de mesurer la difficulté de la mise en place de la surveillance du système d information pour que celui-ci reste opérationnel. Dans un premier temps, nous allons faire une brève présentation du projet. Par la suite, nous étudierons l existant puis l expression des besoins requis pour le projet. Et nous finirons par le planning prévisionnel de la réalisation du projet. Page 3

4 I - Présentation du projet Cahier des charges Projet Supervision 1 - Intitulé Définition du projet : L enregistrement dans un historique des événements de l activité sur le système informatique et leur analyse sont des points importants dans l administration des systèmes d information. Cela permet la construction d'indicateurs pour avoir une vue d ensemble sur différentes informations (connexion utilisateur, envoi/réception mail, trafic web etc.), et la détection d'activités suspectes, d'anomalies ou d'erreurs afin d'agir plus rapidement en cas de besoin. Dans le but d'améliorer la supervision, il est envisagé de modifier, d'installer de nouveaux outils d'analyse des fichiers logs, mais aussi par la suite d'automatiser le plus de tâches possible grâce à des scripts ou des outils déjà existants. 2 - Intérêts et contraintes du projet Afin d apporter une amélioration pour une partie du service de supervision du système d information de l Université, il est demandé de chercher des outils ou de développer des scripts permettant d analyser différents relevés des fichiers logs et d effectuer des actions sur certains services. Dans un cas comme dans l'autre, ce travail nécessite de : Prendre connaissance de l'ensemble des services existants ainsi que les interactions entre eux, par exemple, le mail et l authentification, afin de pouvoir configurer judicieusement un programme d'analyse de log. Maîtriser plus dans le détail certains services pour, le cas échéant, être capable de développer des scripts/outils. Il peut s'agir d'analyser des fichiers de log, relever des grandeurs en temps réels, construire des indicateurs, ou automatiser des tâches déclenchables manuellement ou automatiquement, permettant d analyser différents relevés des fichiers logs et d effectuer des actions sur certains services. Page 4

5 3 - Contexte Le C.R.I. est un service commun de l Université qui a pour mission la mise en place de la politique informatique de l Université. Le C.R.I a notamment les rôles suivants : Il implante et gère les moyens informatiques collectifs et les réseaux, à l'exclusion des équipements bureautiques. Il peut toutefois apporter, dans ce domaine, un conseil quant au choix des équipements. Il élabore et réalise le plan de formation des utilisateurs aux outils qu'il a mis en place. Il assure également une assistance technique aux utilisateurs des logiciels et des réseaux qu'il a implantés. Cette mission ne concerne que les services administratifs. Page 5

6 II - Etude de l existant Cahier des charges Projet Supervision 1 - Architecture du système informatique Le système informatique de l Université d Avignon est supervisé grâce à deux outils : Easymin : Outil développé par le CRI qui permet d effectuer sur les serveurs du système d information des actions, visualiser des informations concernant les comptes utilisateurs, le mail, le web, le FTP, les bases de données. Cet outil a été développé en PHP. Hobbit : Outil qui permet d'observer le fonctionnement du réseau et des serveurs. L'application permet un monitoring en temps réel, et fournit de nombreuses statistiques (disque, processus, log, etc.) et graphiques de performance. Le tout est collecté par un serveur central et mis sous forme de pages web. Page 6

7 2 - Système Mail de l université d Avignon Spam : Désigne les communications électroniques de masse, notamment de courrier électronique, sans sollicitation des destinataires, à des fins publicitaires ou malhonnêtes. Aujourd hui en France, plus de 90% des messages échangés sont des spams. Devant l ampleur du phénomène, des processus sont mis en place afin de filtrer au maximum les boites mail. Cependant, ce filtrage doit être suffisamment fin pour bloquer les spams tout en laissant passer les courriers légitimes. L Université d Avignon possède plusieurs barrières qui lui permettent de lutter contre ce phénomène. a) Black Lists Le service mail de l Université est abonné à une base de données de Black Lists, mis à jour en temps réel. Ce service constitue la première barrière anti-spam de l Université, en refusant les mails en provenance de serveurs et d adresses référencés comme spammeurs. b) Greylisting Le Greylisting est une méthode anti-spam qui se base sur le protocole SMTP. Le courrier en provenance de serveurs inconnus est placé en liste grise, et une erreur temporaire est envoyée au serveur d'émission. Si le protocole est respecté, à la lecture de ce code d'erreur, l'émetteur du message doit placer le mail dans une file d attente avant de tenter de le retransmettre, dans un délai de plusieurs minutes, et celui-ci peut alors être transmis au destinataire. Dans le cas d un serveur utilisé pour le spam, le message n est généralement pas réexpédié, et le mail conservé en mémoire est alors supprimé. c) SpamAssassin Ce logiciel a été mis au point par l Apache Software Foundation (la fondation à l origine du serveur Web Apache), il permet d apporter une troisième barrière anti-spam à l Université. SpamAssassin scanne les mails, et leur définit un score au message. Pour chacun de ces scores, une action est définie, au-delà d un certain seuil ils sont supprimés, certains sont transmis avec la mention ***SPAM***, et enfin les autres sont considérés comme des mails légitimes. Le tout est de définir des seuils adaptés, ni trop stricts car cela risquerait de provoquer des pertes de messages, ni trop laxistes sans quoi il ne serait pas efficace. Page 7

8 III - Expression des besoins Cahier des charges Projet Supervision 1 - Climatisation Il nous a été demandé d'intégrer la supervision des climatisations des salles serveurs afin de pouvoir vérifier leurs conditions de fonctionnement, et en cas de panne de celles-ci de pouvoir remonter une alarme (mail, SMS) pour intervenir dans les plus brefs délais. Pour la climatisation, il va nous falloir analyser des pages HTML afin de surveiller les valeurs que l'on va juger les plus pertinentes. 2 - Mail a) Analyses L analyse des logs du serveur de mail Postfix devrait permettre de détecter au plus tôt et de limiter l'impact d'une attaque de type phishing. Pour cela le logiciel ou le script mis en place devra permettre d obtenir les informations suivantes : Qui a envoyé quoi? L'utilisateur spécifie un intervalle temporel et un ensemble de critères : o o o o o sujet destinataire émetteur adresse IP source recherche d'une chaîne de caractères dans le corps du message Au moins un de ces critères doit être indiqué, et tous acceptent les expressions régulières. Une interface permet de renseigner les différents critères avant de soumettre la recherche. Expression rationnelle (regexp) : en informatique c est une chaîne de caractères que l on appelle parfois un motif et qui décrit un ensemble de chaînes de caractères possibles selon une syntaxe précise. Par exemple [ :digit :] pour les chiffres décimaux ou bien [ :punct :] pour les caractères de ponctuation. Ce sont des exemples d expressions régulières POSIX. Page 8

9 Le trafic des mails doit être surveillé pour détecter de manière automatique les cas suivants : Trop de connexions (seuil paramétrable) : si un utilisateur se connecte trop fréquemment ou si une machine est utilisée pour ouvrir des sessions trop fréquemment, une alerte devra être émise et une action éventuellement déclenchée. Les critères à prendre en compte sont le login, l'adresse IP et un critère temporel (X connexions par Y minutes glissantes) qui devra être paramétrable. C'est le cas quand une machine est infectée et qu'un robot tente de s'identifier pour spammer, ou que le mot de passe a été volé et est utilisé à des fins malveillantes. Un script qui fait déjà cette fonction existe, mais il est à améliorer s'il doit être réutilisé. Les mails entrants : typiquement pour repérer une attaque de type phishing. Dans ce cas-là, une grande quantité de mails est envoyée à différents utilisateurs avec la même adresse de retour. Il faut donc, en fonction d'un critère temporel (X connexions par Y minutes glissantes) qui devra être paramétrable, repérer si la quantité de messages envoyés avec la même adresse de retour dépasse un certain seuil paramétrable. Il se peut aussi que l'adresse de retour varie légèrement (un caractère ou deux qui changent). Les mêmes considérations sont applicables au sujet des messages. Les mails sortants : le but est de détecter très rapidement l'émission de nombreux mails portant le même intitulé de sujet. En effet ce genre de comportement est typique d'un serveur de spam, ce qui pourrait s'avérer extrêmement gênant pour l'université qui pourrait alors se retrouver classée dans les blacklists sur Internet, avec les conséquences que cela aurait sur les mails (messages bloqués dans le cadre d'organismes abonnés aux dites blacklists). b) Actions Les actions doivent pouvoir être déclenchées automatiquement ou manuellement. Suppression/mise en quarantaine de mail des boîtes aux lettres en fonction du sujet/corps du message (support des regexp obligatoires). Interdiction d'envoi de mail (critères : adresse IP, utilisateur). Une interface permet de renseigner les différents critères avant de soumettre la recherche. Si l'action a été déclenchée automatiquement, l'envoi d'un mail doit prévenir l'administrateur de ce qui a été fait. La solution mise en place doit laisser la possibilité d effectuer des actions pour supprimer, mettre en quarantaine et même interdire l envoi des s des boîtes aux lettres en fonction du sujet/corps de texte ou encore en fonction de l utilisateur ou de l adresse IP. c) Statistiques La génération de statistiques, de graphes sur hobbit permettrait d avoir des informations sur le trafic, une meilleure visibilité de l'activité et un meilleur recul de l entrant/sortant et des connexions (POP/IMAP). Cela permettrait aussi de visualiser le traitement des spams de la part de l analyseur Spamassassin : Comptabilisation des mails envoyés, rejetés, reçus, supprimés,... et génération de graphes. Le traitement des spams, rôle de chaque technique (RBLs, greylisting, spamassassin, clamav, non-respects des RFC ), impact du greylisting sur les mails sains, analyse fine des scores spamassassin. Comptabilisation des connexions POP, IMAP et SMTP, mise en place de graphes. Taille moyenne des boîtes aux lettres. Top10 des plus grosses boîtes aux lettres. Page 9

10 Les besoins suivants sont des besoins facultatifs qui seront traités s'il reste du temps après le travail sur les parties climatisation et mail. 3 - Samba Pour la partie Samba, il faut effectuer une génération de statistiques sur les connexions utilisateurs globales ou propres à chacun d entre eux. Il faut aussi trouver un moyen de détecter des problèmes sur les sessions et les brusques augmentations de la place utilisée par les utilisateurs. Pour l'instant seul le nombre d'utilisateurs connectés est surveillé. Il faut trouver un moyen de détecter des problèmes sur les sessions (cela arrive lorsque la session est fermée juste après avoir été ouverte), il faut déterminer un temps minimum endessous duquel on considère qu'il y a un problème. Lorsqu'un tel cas est détecté, il faut déclencher une alerte. Il faut voir aussi si le cas de l'absence du profil par défaut est détectable facilement ainsi que le cas de l'absence du répertoire du groupe. Voir si SAMBA autorise l'exécution d'un script à la fermeture/ouverture d'une session. Mettre en place un mécanisme permettant de détecter les brusques augmentations de place disque occupée par les utilisateurs (seuil à déterminer). 4 - Apache Sur le service web, il faut apporter une amélioration sur la génération des statistiques des hôtes virtuels, mais aussi mettre en place un outil d analyse de log permettant de détecter des tentatives d attaques de site web : Analyse pour détecter les tentatives d'attaques exploitant des failles potentielles Amélioration de la génération des statistiques. Il y a actuellement deux serveurs mais les logs d'un seul serveur sont analysés. Il faudrait modifier le script existant pour qu'il prenne en compte tous les logs. Faire un top 10 des virtualhosts par nombre de visiteurs et par bande passante. 5 - DNS Pour le service DNS, il faut faire la recherche d outils/scripts existants déjà afin de permettre l analyse des logs de Bind. Dans le cas contraire il sera nécessaire de développer un script. La valeur la plus pertinente est le nombre de requêtes effectuées dans une journée, donc un refresh une fois par nuit pour chaque domaine serait largement suffisant. Page 10

11 6 - MySQL Dans le cadre de notre projet il faudrait générer un graphe permettant de retracer le nombre de requêtes par seconde envoyées à la base de données. Page 11

12 IV - Planning prévisionnel Cahier des charges Projet Supervision 1 - Planning du premier semestre Notre premier travail a consisté à définir les besoins du projet. Pour cela nous avons rencontré notre tuteur ainsi que Stéphane Igounet et Eric Innoncente. Cela nous à permis d'étudier l'architecture du système informatique de l'université, ainsi que son architecture mail. Une fois les besoins de chacun définis nous avons pu commencer à rédiger le cahier des charges. 2 - Planning prévisionnel du second semestre Pour le deuxième semestre, nous allons commencer par travailler sur Hobbit afin de mettre en place la partie climatisation. Ce travail qui devrait nous prendre une ou deux semaines nous permettra de découvrir ce logiciel, ainsi que l'implantation de scripts. Une fois la partie "découverte" terminée, nous pourrons alors nous attaquer au "gros morceau" qu'est la partie mail du projet. Dans un premier temps il va nous falloir poursuivre la recherche de solutions : scripts existants, logiciels, puis choisir la plus appropriée à notre cahier des charges et l'adapter à la structure de l'université. Si nous ne trouvons pas de solution il faudra alors la construire nous même, probablement à partir de scripts perl. Pendant le mois d'avril et de mai nous pourrons tester, puis intégrer notre travail au sein de l'université afin de le rendre fonctionnel. Les autres parties du cahier des charges (DNS, SAMBA, ) pourront être mises en place au fur et à mesure de l'avancée du projet si nous trouvons les outils appropriés et le temps pour le faire. Page 12

13 Conclusion Lors de ce premier semestre, nous avons pu découvrir le fonctionnement du système informatique et mail de l'université d'avignon. En nous basant sur ces études, nos connaissances, ainsi que l'expression des besoins formulés par les différents administrateurs, nous avons été à même de définir un cahier des charges qui nous servira de base pour le deuxième semestre. Après cette étude théorique, nous allons pouvoir commencer à tester les solutions qui nous paraissent les plus appropriées. Dans un premier temps nous allons travailler sur la climatisation, ce qui nous permettra de découvrir l'implantation de script, ainsi que les outils d'administration de façon plus détaillée (Easymin et Hobbit). Nous pourrons ensuite nous occuper de la partie principale qui concerne les mails. Si nous en avons le temps nous nous chargerons également des parties SAMBA, Apache, DNS et MySQL. A la fin du deuxième semestre, notre travail permettra donc aux administrateurs de gérer plus facilement le réseau de l'université grâce à des outils polyvalents centralisés a partir de Hobbit ou Easymin. De notre côté ce projet nous permettra d'acquérir des compétences dans la création, la modification et l utilisation de script dans le cadre de l'administration d'un réseau en exploitation. Nous verrons aussi en détail la façon dont est mis en place un système d information ainsi que les différents éléments qui le composent. Ces différentes compétences, nous resservirons inévitablement dans nos futurs emplois. Page 13