Agate-Secure Guide de référence 1
Sommaire 1. Introduction... 4 1.1. Contextualisation... 4 1.2. Le réseau d Euro-Information... 4 1.2.1. Schéma simplifié du réseau d Euro-Information... 4 1.2.2. Fonctionnement interne de la sécurité... 5 1.3. Objet du stage... 5 2. Architecture générale de l application... 5 2.1. Finalités de l application... 5 2.1.1. La gestion des demandes d ouverture firewall... 5 2.1.2. La gestion de l inventaire du parc sécurité... 6 2.1.3. La gestion de la configuration des serveurs de configuration et de journalisation... 6 2.2. Deux types d utilisateurs... 6 2.2.1. Les utilisateurs du SI... 6 2.2.2. Les administrateurs... 7 2.2.2.1. Cas général... 7 2.2.2.2. Cas particulier... 7 2.2.2.3. Second cas particulier... 7 2.3. La base de données... 8 3. Agate-Secure du côté utilisateur «simple»... 9 3.1. Utilité pour l utilisateur Lambda... 9 3.2. Qu est ce qu une «demande firewall»... 9 3.3. Schéma explicatif... 9 3.4. Du point de vue fonctionnel... 10 3.4.1. Les demandes utilisateur... 10 3.4.1.1. Lors d une complétion manuelle... 11 3.4.1.2. Complétion automatique du formulaire par import depuis un fichier XML... 13 3.4.1.2.1. Format du fichier XML... 13 3.4.1.2.2. Analyse syntaxique... 14 3.4.1.2.3. Exemple de fichier... 14 3.4.1.3. Exportation vers un fichier XML... 15 3.5. Du point de vue technique... 15 3.5.1. Le formulaire des demandes utilisateurs... 15 3.5.1.1. Import depuis un fichier XML... 15 3.5.1.2. Validation d une demande... 16 3.5.1.3. Export vers un fichier XML... 17 4. Agate-Secure du côté administrateur (ou la face cachée de l iceberg)... 19 4.1. Introduction... 19 4.2. Quelques définitions... 19 4.2.1. Serveur de Journalisation... 19 4.2.2. Serveur de configuration... 19 4.2.3. Cluster... 19 4.3. Les fonctionnalités administrateur en détails... 20 4.3.1. Liste des demandes... 20 4.3.1.1. La gestion des demandes utilisateur par les administrateurs... 21 4.3.1.2. Du point de vue technique... 25 4.3.2. Le menu administration... 30 4.3.2.1. Users : Ajouter... 30 4.3.2.2. Users : Modifier... 30 4.3.2.3. Users : Supprimer... 30 4.3.2.4. Users : Postes users... 32 4.3.2.5. Users : Gestion des autorisations... 33 4.3.2.6. Users : Accès serveur de journalisation... 34 4.3.2.7. Catégorie «Système»... 35 4.3.3. Le menu Gestion de parc... 36 4.3.3.1. Gestion de parc : Liste des firewalls... 36 4.3.3.1.1. Edition d un serveur de journalisation... 36 4.3.3.1.2. Edition d un firewall... 38 4.3.3.1.3. Modification d un serveur de configuration... 40 5. Agate-Secure et la configuration des serveurs de journalisation... 40 5.1. Script n 1... 40 5.2. Script n 2... 40 6. Conclusion... 41 2
3
1. Introduction 1.1. Contextualisation Euro-Information production gère le système informatique du groupe Crédit Mutuel et du CIC. Le département informatique se doit de posséder une stratégie sécuritaire cohérente qui se présente sous différentes formes : - La sécurité physique (ex. contrôle d accès des locaux, marquage des équipements, ) - La sécurité de l exploitation (ex. gestion des incidents, plan de sauvegarde, ) - La sécurité logique (ex. contrôle d accès logique(identifiants, mot de passe), chiffrement, ) - La sécurité applicative (ex. sécurité des progiciels, validation et audit des programmes, ) - La sécurité des télécommunications (ex. firewall, DMZ, protocole de communication sécurisés, ) La mise en place de cette stratégie et son maintient sont l œuvre de plusieurs équipes dont les missions mises bout à bout contribuent au fonctionnement de la politique de sécurité. Ainsi, une des équipes, dite de «sécurité réseau», est en charge de la sécurité des télécommunications. Ses missions passent par la gestion des firewalls de l entreprise, leur installation, leur configuration et leur mise à jour. Le contrôle des accès logiques et la journalisation de tous les évènements du réseau. Pour parvenir à ses fins, l équipe a à sa disposition de nombreuses ressources matérielles. Étudions-les. 1.2. Le réseau d Euro-Information 1.2.1. Schéma simplifié du réseau d Euro-Information Figure 1.2.1-1 Schéma simplifié du réseau d'euro-information 4
Pour la compréhension de certaines parties de ce document, il est important de savoir comment se présente le réseau d Euro-Information. Ce schéma est bien évidemment simplifié pour des raisons à la fois de simplicité de compréhension mais aussi pour des raisons de sécurité. Ce qu il faut bien faire ressortir de ce schéma sont les choses suivantes : - Le réseau est divisé en plusieurs sites (Nantes, Paris, ) - Il existe un réseau central, que nous appellerons «nébuleuse». Chaque site est relié à «nébuleuse», et il y a toujours un ou plusieurs firewalls entre qui sépare le site de «nébuleuse». - Chaque site est composé de plusieurs firewalls 1.2.2. Fonctionnement interne de la sécurité Sur le réseau d Euro-Information sont installés différents matériels de protection aux finalités différentes. On a d un coté le matériel de gestion et d analyse des flux réseaux, les firewalls matériels, ou logiciels, alors embarqués sur un matériel propriétaire sur lequel on met une solution propriétaire. Ces firewalls filtrent le trafic réseau. De l autre coté les serveurs de journalisation, matériel serveur embarquant des solutions propriétaires de journalisation. On les appelle des serveurs serveur de journalisation et serveurs serveur de configuration. Nous ne développerons pas plus le fonctionnement de ces serveurs car cela dépasserait le cadre de ce document, cependant il est nécessaire de savoir qu ils existent car, nous le verrons plus loin, la solution logicielle explicitée dans cette documentation à, entre autre, en charge une partie de la gestion de ces serveurs. Toutes ces ressources au vue de leur nombre et afin de faciliter leur maintient par les administrateurs se doivent voir greffer une solution de gestion. Ceci nous mène donc à l objet technique de mon stage. 1.3. Objet du stage Cette solution de gestion est un applicatif développé en interne par Maël Thominet de l équipe «sécurité réseau». Cependant au fil du temps les besoins évoluant, pour être de plus en plus importants, et le manque de temps, ne permettent plus un développement efficace et rapide de l application. Il m a ainsi été confié la refonte totale de cette application. Cette refonte allant de la mise aux normes de la charte graphique de l entreprise, à la réécriture des fonctions internes et à l ajout de fonctionnalités dans le but d une productivité et d une facilité de maintient accrue. L application se nomme Agate-Secure. Cet applicatif est écrit en PHP, utilise les technologies JavaScript et CSS, travaille sur des bases de données MySQL et fait du traitement de fichiers XML. Une partie plus spécifique a été écrite en Bash. Nous allons l aborder sous ses différents aspects dans les chapitres suivants. Tout au long du document nous remarquerons des parties expliquant la façon de se servir de l application. La première idée venant à notre esprit peut être alors «une documentation technique n est pas un manuel d utilisation», ce qui est légitime. Cependant, la résolution d un problème passe d abord par sa compréhension, il apparait donc indispensable que le(s) futur(s) programmeur(s) sachent se servir de l application avant de la développer à leur tour. 2. Architecture générale de l application 2.1. Finalités de l application 2.1.1. La gestion des demandes d ouverture firewall Agate-Secure est né de la nécessité de pouvoir sécuriser le parc informatique en impactant d une façon moindre les utilisateurs. La gestion des demandes d ouverture firewall est donc l utilité première de cette application. 5
2.1.2. La gestion de l inventaire du parc sécurité La gestion du parc sécurité découle directement de la première finalité d Agate-Secure. Car il va de soit que dès lors que l on veut gérer les demandes d ouverture firewall, il faut référencer les firewalls présents dans l entreprise afin de pouvoir modifier leur configuration. 2.1.3. La gestion de la configuration des serveurs de configuration et de journalisation Les serveurs de configuration et les serveurs de journalisation font partie intégrante de la sécurité de l entreprise. Les serveurs de configurations sont les serveurs qui vont modifier les règles des firewalls. Les serveurs de journalisation, même s ils n ont pas de rapport direct avec les firewalls ont été intégrés à Agate-Secure car ils sont nécessaire à une bonne politique de sécurité. L application tend d ailleurs avec le temps à s ouvrir vers une optique plus large que la «simple» gestion des règles de firewall. Ainsi, il est possible à travers des formulaires de l application, de changer les droits d accès des utilisateurs aux serveurs de journalisations. C est cette partie qui a été développée en Bash. Nous y revenons au chapitre 5. 2.2. Deux types d utilisateurs Agate-Secure est accessible à deux sortes d utilisateurs différents, chacun ayant accès à deux parties de l application bien différentes. 2.2.1. Les utilisateurs du SI Les utilisateurs du SI ne peuvent effectuer qu un seul type d action sous Agate-Secure : la saisie d une «demande d ouverture firewall». Cette demande ce fait via un formulaire en ligne à l adresse : http://agate-secure.cm-cic.fr/ L utilisateur doit entrer différentes informations : - Demandeur (qui demande?) - Type de demande (ajout de règle, résiliation d une ancienne demande, modification) - Type de service (numéro de port : ex. 25, ou, nom : ex. SMTP) - Sens (de A vers B, de B vers A, ou dans les 2 sens) - Date de réalisation souhaitée - Date de résiliation souhaitée Cette demande transite ensuite par plusieurs états : - Validation technique : la demande est elle réalisable techniquement? - Validation administrative : la demande est elle acceptée par l administration? Décision essentiellement politique. - Etat «mise en place» : la demande a passé les deux validations, et a été mise en place. L utilisateur à l origine de la demande voit le flux d information accepté par les firewalls et peut désormais utiliser son application. Si l une des deux validations est refusée, la demande n abouti pas et l utilisateur en est informé par mail avec la raison du refus. Si les deux validations sont acceptées, alors la règle firewall est mise en place et l utilisateur en est averti par mail. Dans le cas ou une demande est formulée, et que le firewall laisse déjà passer le flux, l utilisateur en est aussi informé. 6
2.2.2. Les administrateurs 2.2.2.1. Cas général Les administrateurs sécurité sont en charge de la validation technique et de la mise en place des demandes d ouverture firewall effectuées par les utilisateurs. Ils accèdent à leur console de gestion via la même adresse que les utilisateurs normaux. Cependant, les administrateurs ne sont pas tous habilités à accepter telle ou telle demande. En effet, les demandes effectuées concernent généralement un site précis, par exemple, une demande peut concerner le site de Paris. Ainsi, un administrateur se trouvant sur le site de Nantes n aura pas le droit d effectuer une validation pour ce site, mais cette demande apparaitra tout de même dans sa console. Pour une demande concernant plusieurs site (ex. demande d ouverture de port 25 sur le firewall de Nantes vers le port 25 d un serveur situé à Brest), chaque administrateur doit valider de son côté. La demande passe en étape «validation administrative» uniquement lorsque toutes les validations techniques ont été acceptées. Ainsi, tout refus de la part d un administrateur invalide la demande de l utilisateur. La validation administrative, elle, est globale. Une seule personne s occupe de la validation. Si la demande a transité par toutes ces étapes alors elle est mise en place. Chaque administrateur applique sur son/ses firewall la règle et l utilisateur est averti. 2.2.2.2. Cas particulier Il arrive parfois qu un administrateur, lors de la phase de validation technique ou administrative, détermine qu il peut être utile d appliquer la demande à l ensemble des sites. Il peut alors, via un bouton du formulaire, proposer la mise en place de la règle en «globale», c est-à-dire, à tous les sites. La demande de mise en globale est soumise à la validation technique d administrateurs autorisés «globale». Cependant, le refus d une mise en globale n annule pas la demande. 2.2.2.3. Second cas particulier Nous venons de parler des administrateurs «autorisés globale». Il existe en réalité 2 catégories d administrateurs, les administrateurs dit «normaux» et les administrateurs dits «autorisés globale». Ce terme décrit un type très particulier d administrateurs, ces derniers ne sont d ailleurs que 4 dans tout le réseau d Euro-Information. Leur spécificité est de pouvoir valider une demande alors que celle-ci ne concerne pas le site qu ils administrent. 7
2.3. La base de données Figure 2.3-1 La base de données Agate-Secure Ce schéma présente l architecture de la base de données d Agate-Secure, pierre angulaire de tout le projet. 8
3. Agate-Secure du côté utilisateur «simple» 3.1. Utilité pour l utilisateur Lambda 3.2. Qu est ce qu une «demande firewall» Les utilisateurs du SI (directeurs d agences, employés, administrateurs système, administrateurs Unix, etc.) sont souvent amenés à utiliser différentes applications communiquant à travers le réseau. Le SI étant doté d une politique de sécurité stricte, la plupart de ces applications ne peuvent fonctionner car leur flux d information se trouve filtré par les firewalls. Il est donc nécessaire de mettre en place une application capable de débloquer les flux, sans aller à l encontre de la politique de sécurité, afin que ces utilisateurs puissent travailler. Agate-Secure répertorie les demandes d ouverture de flux à une fin d analyse qui mènera par la suite à l acceptation -ou non acceptation-, par un administrateur, de l ouverture de l accès. 3.3. Schéma explicatif Figure 3.3-1 Schéma du cheminement d une demande d ouverture firewall 9
3.4. Du point de vue fonctionnel 3.4.1. Les demandes utilisateur Lorsque l utilisateur se connecte à l adresse : http://agate-secure.cm-cic.fr il est automatiquement identifié grâce au système d identification automatique standard développé par Euro Information. Suite à cette identification, Agate-Secure recherche dans sa base de données les droits de cet utilisateur. S il est utilisateur simple, alors il n a accès qu aux onglets : - Nouvelle demande firewall - Demande de suppression - Demande de modification Lors d une nouvelle demande, l utilisateur à plusieurs choix : - Soit il possède un fichier.xml contenant la nouvelle demande d ouverture, alors il lui suffit de cliquer sur «importer depuis fichier XML» et le formulaire se complétera seul. - Soit, il ne possède pas de fichier pré renseigné et il doit compléter lui-même le formulaire. - Soit, l utilisateur souhaite enregistrer sur son disque sa demande et dans ce cas il doit cliquer sur «exporter vers un fichier XML». S il clique sur ce bouton il est invité à enregistrer un fichier.xml contenant sa demande sur son disque. Par manque de temps, les deux choix restant, «demande de suppression» et «demande de modification» n ont pas pu être développés et intégrés à l application. Ces deux modules n étaient, en outre, pas prioritaires. 10
3.4.1.1. Lors d une complétion manuelle Figure 3.4.1.1-1 Formulaire de complétion manuelle L utilisateur doit remplir plusieurs champs : - Demandeur : il correspond à l adresse email du demandeur, elle est pré renseignée automatiquement par l application, mais elle peut être changée si l utilisateur fait la demande au nom d un autre. (en effet, il n est pas rare que les utilisateurs ne comprennent pas les champs demandés par l application et demande alors l aide d un collègue). - Extrémités : une demande firewall est constituée d au minimum 2 extrémités, une source, et une destination. Pour chaque extrémité, l utilisateur doit renseigner une adresse IP ainsi qu un nom. Le masque n est pas obligatoire, il est nécessaire si l utilisateur souhaite spécifier un réseau entier. S il n est pas rempli l extrémité est considérée comme étant une machine. L utilisateur peut ajouter ou supprimer des extrémités à sa convenance, il n y a pas de limite maximum en nombre d extrémités, il peut y avoir plusieurs sources et plusieurs destinations, cependant, l utilisateur ne peut plus supprimer d extrémité dès lors qu il n en reste que 2. Pour supprimer une extrémité il suffit de cocher la case «supprimer» puis de cliquer sur le bouton «supprimer extrémité». - Date de réalisation souhaitée : elle correspond à la date à laquelle l utilisateur souhaite voir sa demande mise en place sur les firewalls. Lorsque que l utilisateur clique sur cette zone un calendrier s affiche, il n a dès lors plus qu à sélectionner la date souhaitée. - Date de résiliation souhaitée : elle correspond à la date à laquelle l utilisateur souhaite voir sa demande invalidée sur les firewalls. Un calendrier s affiche aussi lorsque l utilisateur clique sur cette zone. Il peut choisir «jamais» dans le cas ou il souhaiterait que sa demande soit permanente. 11
- Services : il correspond aux services que l utilisateur souhaite ouvrir sur les firewalls. Il y en a au minimum 1. L utilisateur peut compléter le «nom» s il le connait, mais doit impérativement compléter le «port». Il doit ensuite choisir le sens dans lequel il veut que le flux soit ouvert en cliquant sur la flèche située sous «sens». Trois choix lui sont permis : 1. Le service doit être ouvert de/des source(s) vers la/les destination(s) 2. Le service doit être ouvert de/des destination(s) vers la/les source(s) 3. Le service doit être ouvert dans les 2 sens L utilisateur peut ajouter autant de services qu il le souhaite. Il peut en supprimer en procédant de la même manière que pour supprimer une extrémité. - Justification : c est le dernier champ, il n en est pas moins important. Il est la motivation de la demande. Ce champ est obligatoire car il permet aux administrateurs sécurité de déterminer si l ouverture d un flux sur les firewalls est réellement justifiée. Après avoir rempli tous les champs, l utilisateur doit cliquer sur «valider». La demande est alors transmise. Exemple d une demande complète : Figure 3.4.1.1-2 Demande complétée 12
3.4.1.2. Complétion automatique du formulaire par import depuis un fichier XML Un utilisateur peut aussi importer une demande contenue dans un fichier en format XML. A la suite de cette importation, le formulaire sera complété par les informations contenues dans le fichier. L utilisateur n a plus qu à vérifier que les informations sont bonnes et à valider. Figure 3.4.1.2-1 Formulaire de sélection du fichier XML 3.4.1.2.1. Format du fichier XML Afin d être correctement analysé, le fichier doit respecter scrupuleusement la forme suivante : <?xml version="1.0" encoding="utf-8"?> <Demandes> <Demande type=""> <demandeur email=""></demandeur> <Extremites> <extremite nom="" ip="" masque="" type=""></extremite> </Extremites> <Services> <service nom="" port="" protocole="" sens=""></service> </Services> <daterealistation date=""></daterealistation> <dateresiliation date=""></dateresiliation> <Justification texte=""></justification> </Demande> </Demandes> 13
<Demandes> Elle est la balise racine. 3.4.1.2.2. Analyse syntaxique <Demande type=""> Elle délimite une demande et spécifie son type. Ce dernier peut être soit «ajout», «modification» ou «suppression». <demandeur email=""> Elle détermine le demandeur. Ce dernier est identifié par son adresse mail. L attribut «email» doit être l adresse mail du demandeur. <Extremites> Elle délimite le début la section des extrémités. Elle contient la balise <extremite nom="" ip="" masque="" type=""> qui détermine une extrémité en particulier. Son «ip» doit être en notation décimale pointée, le «masque» en notation abrégée, et le «type» peut être soit «source» soit «destination». Le masque peut être vide ou mis à NULL. <Services> Elle délimite le début de la section des services. Elle contient la balise <service nom="" port="" sens=""> qui détermine un service en particulier. Le «port» doit être un nombre compris entre 1 et 65535. Le «sens» doit être égal à «0» pour un service à ouvrir de la source vers la destination, «1» pour un service à ouvrir de la destination vers la source, «2» pour un service à ouvrir dans les deux sens. <daterealistation date=""> <dateresiliation date=""> Ces deux champs correspondent respectivement à la date de mise en place souhaitée et à la date de résiliation souhaitée. Elle doit être au format MySQL, c'est-à-dire au format aaaa-mm-jj. <Justification texte=""> Ce champ est la justification de la demande. C est l attribut «texte» qui doit contenir le texte de justification. 3.4.1.2.3. Exemple de fichier <?xml version="1.0" encoding="iso-8859-2"?> <Demandes> <demande> <demandeur email='alaryhu@e-i.com' ></demandeur> <Extremites> <extremite nom='extremite1' ip='192.168.0.1' masque='32' type='0'></extremite> <extremite nom='extremite2' ip='192.168.0.2' masque='' type='1'></extremite> <extremite nom='extremite3' ip='192.168.0.3' masque='' type='0'></extremite> </Extremites> <Services> <service nom='ssh' port='22' sens='0'></service> <service nom='http' port='80' sens='1'></service> <service nom='ftp' port='21' sens='2'></service> <service nom='autre' port='8080' sens='0'></service> </Services> <daterealisation date='2007-10-02'></daterealisation> <dateresiliation date='2007-10-17'></dateresiliation> <Justification texte='demande de test'></justification> </demande> </Demandes> 14
3.4.1.3. Exportation vers un fichier XML L Utilisateur souhaitant exporter sa demande vers un fichier XML doit cliquer sur le lien suivant : Une fenêtre de téléchargement s ouvrira : Figure 3.4.1.3-1 Fenêtre de téléchargement du fichier XML généré par l'application 3.5. Du point de vue technique 3.5.1. Le formulaire des demandes utilisateurs Le formulaire utilisé afin d effectuer des demandes d ouverture firewall correspond au fichier adddemande.php. 3.5.1.1. Import depuis un fichier XML Le script PHP appelle le script «adddemande_importer_xml.php» lequel demande le chemin du fichier à importer : Lorsque l utilisateur clique sur «ouvrir» le script appelle «adddemande_actions_xml.php» avec un paramètre «type» égal à «lecture», le fichier est alors lu et parsé grâce aux fonctions standard de parsing intégrées à PHP. Le formulaire de demande est rempli par les informations tirées du fichier XML. 15
Figure 3.5.1.1-1 Schéma du fonctionnement de l import d une demande en XML 3.5.1.2. Validation d une demande Le script PHP appelle un script «requete_adddemande.php». Ce dernier récupère via la variable $_POST tous les champs précédemment listés. Pour chaque extrémité il est vérifié que : - l adresse IP est valide (notation décimale pointée, chaque nombre strictement inférieur à 256). - s il est complété, le masque est valide (notation abrégée). - le champ «nom» n est pas vide. - il y a au moins une source et une destination de définies. Pour chaque service il est vérifié que : - le port est renseigné et strictement inférieur à 655356 et strictement supérieur à 0. Le script regarde si les dates de réalisation et de résiliation ont été complétées ainsi que la justification. Si l une des vérifications échoue, la demande n est pas enregistrée, le programme retourne un/des message(s) d erreur, le formulaire reste cependant complété. Si la vérification aboutie, le script effectue alors différentes requêtes sur la base de données : Une première requête créant la demande et l identifiant unique correspondant : - INSERT INTO TableDemandesFW (datedemande,demandeur,justification,daterealisationsouhaitee,dateresiliation Souhaitee) VALUES demandeur,justification,daterealisationdemande,dateresiliationdemande Pour chaque extrémité : - INSERT INTO DemandesExtremites(ID_Demande,Type,IP,Masque,Nom) VALUES ID_Demande, Type, IP, Masque, Nom 16
Pour chaque service : - INSERT INTO DemandesServices(ID_Demande,nom,port,sens) VALUES ID_Demande,nom,port,sens Figure 3.5.1.2-1 Schéma du fonctionnement d une nouvelle demande 3.5.1.3. Export vers un fichier XML Le script PHP appelle le script «adddemande_actions_xml.php» avec un paramètre «type» égal à «creation». Le programme récupère chaque champ et créer le fichier xml grâce à une bibliothèque récupérée sur www.phpcs.fr. Le fichier n est pas créé sur le serveur, il est directement envoyé au navigateur client grâce à l appel d un script «xml/ envoie_xml_demandefw.php» auquel est passé en paramètre le fichier xml. 17
Figure 3.5.1.3-1 Schéma du fonctionnement de l exportation d une demande vers un fichier XML 18
4. Agate-Secure du côté administrateur (ou la face cachée de l iceberg) 4.1. Introduction Agate-Secure possède une seconde finalité qui est uniquement visible par les administrateurs sécurité. Il gère l inventaire du parc de firewall, ainsi que les serveurs serveur de journalisation et serveur de configuration cités en introduction. Chaque firewall, serveur de journalisation ou serveur de configuration présent dans l entreprise est répertorié dans l application. Chaque type de matériel possède une fiche répertoriant toutes les informations utiles aux administrateurs (ex. nom, nombres d interfaces, zone géographique, ram, numéro de série, ). Agate-Secure permet l ajout, la modification ou la suppression d un matériel, mais ne s arrête pas là. Ce matériel, comme tout outil informatique, nécessite une administration et gère par conséquent en son sein des accès utilisateurs. Chaque utilisateur ayant des droits différents, selon ses attributions dans l entreprise, son domaine de compétence, etc. Il est ainsi possible aux administrateurs d ajouter, modifier, ou supprimer les accès logiques à ces matériels. Le principal avantage résidant dans le fait que ces modifications sont centralisées. Sans cette solution, un administrateur voulant modifier les droits d un utilisateur sur plusieurs serveur de journalisation devraient se connecter sur chaque serveur de journalisation, un par un, pour effectuer les modifications. Ici, il n a qu à rempli un champ et à cliquer pour voir ses modifications répercutées sur tous les serveurs de configuration concernés. 4.2. Quelques définitions Les deux définitions suivantes sont nécessaires à la compréhension du document, elles ne s attardent cependant pas sur les détails du fonctionnement interne, car, comme il est dit au début de ce document, ils sortent du strict du fonctionnement d Agate-Secure. 4.2.1. Serveur de Journalisation Le serveur de journalisation est un serveur de collecte des journaux d événements dédié. Il rend la visualisation des journaux d événements plus performante pour les clients amenés à gérer un grand nombre de points d accès en déchargeant le serveur d administration des opérations de journalisation. 4.2.2. Serveur de configuration Un serveur de configuration est un client virtuel de gestion. Le serveur de configuration gère les points de sécurité de l entreprise, par exemple, ses firewalls. A travers un serveur de configuration, un administrateur peut créer des politiques, règles, pour les firewalls qu il gère. 4.2.3. Cluster Un cluster est un regroupement de firewalls. En général, un cluster est constitué de 2 firewalls, il se peut cependant que parfois il n y ai qu un seul firewall (on appellera alors le cluster un «firewall autonome») ou plus de 2 firewalls. 19
4.3. Les fonctionnalités administrateur en détails Lorsque qu un administrateur se connecte à l application, il est, comme tous les autres utilisateurs, automatiquement identifié, mais Agate-Secure détecte alors son statut d administrateur et lui offre alors deux nouveaux menus, contenant eux même plusieurs sous menus. Figure 4.3-1 Menu Administration Figure 4.3-2 Menu Gestion de parc Il est ainsi possible à l administrateur via le menu «Administration» de : - Lister les demandes d ouverture firewall en cours - Ajouter, modifier, supprimer des utilisateurs - Gérer les postes utilisateur - Gérer les autorisations au niveau des clusters - Gérer les accès aux serveurs de journalisation Et via le menu «Gestion du parc» : - Lister les firewalls (cela liste en réalité aussi les serveurs de configuration) - Ajouter des serveurs de journalisation - Ajouter des Firewalls - Ajouter des serveurs de configuration - Editer la hiérarchie des clusters 4.3.1. Liste des demandes Ce lien apparait juste au dessus du menu «administration» mais n est accessible uniquement par les administrateurs. Il sert à la gestion des demandes d ouverture firewall. 20
4.3.1.1. La gestion des demandes utilisateur par les administrateurs Une fois la demande effectuée, celle-ci est accessible aux administrateurs, qui, après analyse, la valideront ou non. L accès à la liste des demandes en cours se fait via le menu «liste des demandes», menu uniquement visible lorsque l on est administrateur. Ce menu renvoi à une page listant toutes les demandes d ouverture firewall en cours de validation : Figure 4.3.1.1-1 Formulaire listant les demandes en cours Les informations les plus importantes à propos des demandes sont listées. La demande apparaissant en bleu est la demande sur laquelle se trouve la souris. Un clic sur cette demande mène à une page détaillant encore un peu plus les informations concernant la demande. 21
Figure 4.3.1.1-2 Formulaire récapitulant une demande Sur cette page on remarque différents champ. Le champ «Schéma demande» explicite simplement la demande de façon à ce que celle si soit facilement lisible. Ce champ divise la demande en 3. A gauche, les «extrémités sources», triées par IP, au milieu, les services, triés par sens, et à droite, les «extrémités de destinations» triées elles aussi par adresse IP. On remarque par ailleurs la présence de petits sigles devant chaque extrémité. Ce sigle indique que l adresse IP est celle d un hôte Celui-ci signifie que l adresse IP est celle d un réseau En dessous, le programme fait la «liste des clusters concernés par la demande». Cette liste est utile aux administrateurs car elle leur indique les firewalls dont ils auront à modifier les règles afin que les flux dont l ouverture est demandée fonctionnent. On remarque ensuite la présence d un champ jaune, «proposition en global». Ce champ peut être coché par un administrateur si celui-ci pense qu il peut être utile d appliquer la demande à tout le système d Euro-Information. Enfin, les administrateurs on l état des différents stades de validations (cf. schéma explicatif en 2.2). Dans la mouture actuelle de l application, seul l état des «validations technique» (= la demande est-elle réalisable techniquement?) est disponible car je n ai malheureusement pas eu le temps de développer le reste. La liste des validations technique est divisée en plusieurs colonnes : - Etat : indique si la demande est en attente ( ), acceptée ( ) ou refusée ( ), mais elle peut aussi prendre les valeurs «firewall passant» ( ) ou «déjà en place» ( ). La valeur «firewall passant» signifie que le firewall ne filtre aucun flux, autant dire que cette valeur est très rare. La valeur «déjà en place» signifie que pour ce firewall ci, la règle d ouverture du flux existe déjà. - Cluster : indique le cluster firewall concerné - Valideur : le nom du valideur 22
- Date de validation : la date à laquelle l administrateur en charge du cluster concerné à validé la demande - Commentaire : le commentaire de l administrateur ayant validé la demande. En temps normal, ce commentaire est optionnel. Cependant, le fait de refuser une demande rend ce champ obligatoire. Tout refus doit être justifié par l administrateur. - Actions : ce champ regroupe toutes les actions réalisables par l administrateur à savoir : 1. Accepter 2. Refuser 3. Déjà en place 4. Firewall passant On remarque sur la capture que le cluster «cluster_firewall_2» est en attente de validation, mais que les boutons servant normalement à valider la demande ne sont pas présents. Cela est dû au fait que l administrateur qui regarde cette demande n a pas autorité sur ce cluster. Il n a donc pas le droit de le valider. Il existe cependant un cas ou, même si l administrateur n a pas autorité, il a quand même accès aux boutons de validation. Ce cas est celui des admins «autorisés globale». Pour ces administrateurs, et uniquement eux, la page qui s affiche est très légèrement différente : On peut noter qu un des champs «commentaire» apparait en gris sur la capture. Ce champ en gris indique à l administrateur qu il peut effectuer une validation pour ce cluster car il est administrateur «autorisé globale» MAIS qu il n a normalement pas autorité dessus, et que par conséquent, il ne devrait pas effectuer quelconque action dessus. Voici un autre exemple de formulaire de validation pour une demande plus conséquente : 23
Figure 4.3.1.1-3 Formulaire sans aucune validation Exemple d une demande dont toutes les validations ont été effectuées : 24
4.3.1.2. Du point de vue technique La partie intéressante techniquement dans ce formulaire, est celle concernant la liste des clusters concernés. Comment cette liste est elle générée? Comment le programme a-t-il déterminé quels sont les clusters firewalls qu il va falloir modifier afin que les flux de la demande soient ouverts? Lorsque qu un utilisateur émet une demande, le script PHP exécute un algorithme. Pour chaque extrémité renseignée dans la demande, l algorithme va chercher derrière quel cluster se trouve cette extrémité. Si 2 extrémités se trouvent derrière le même cluster, le programme n enregistre qu une seule fois l information. 25
Voyons en détails le fonctionnement de cet algorithme : L algorithme est scindé en deux parties : 1. Trouver le cluster firewall auquel appartient l extrémité grâce à la table «IPtoCluster» 2. Trouver derrière quel(s) cluster(s) firewall le cluster précédant se trouve grâce à la table «Firewall_clusters» Imaginons la disposition réseau suivante : Une demande d ouverture de flux de l hôte A vers l hôte B a été demandée par un utilisateur. Le programme doit déterminer quels sont les clusters firewall traversés par la demande. 1 ère partie de l algorithme : La table «IPtoCluster» contient les adresses IP des réseaux qui se trouvent derrière tel ou tel cluster. Elle possède la structure suivante : - IP - Masque - Cluster immédiat - Description - IP Binaire Par exemple, le réseau 10.17.250.0/24 se trouvant juste derrière le cluster firewall CLUSTER_FIREWALL_1 sera contenu dans la table sous la forme suivante : - 10.17.250.0-24 - CLUSTER_FIREWALL_1 - Réseau facturation - 00001010000100011111101000000000 26
Et le réseau 10.45.0.1/18 derrière le cluster firewall 18 : - 10.17.45.0.1-18 - CLUSTER_FIREWALL_18 - Réseau Parisien - 00001010001011010000000000000001 Algorithme de recherche du cluster le plus proche Afin de trouver à quel cluster firewall appartient l extrémité A (10.17.250.1) le programme converti l adresse IP et le masque de sous réseau en binaire. Ce qui donne 00001010000100011111010100000001 et 111111111111111111000000000000000. Le programme effectue ensuite un ET logique entre l adresse IP et le masque de sous réseau. Le résultat est ensuite récupéré et comparé aux données contenues dans la base de données. On obtient alors le nom du cluster firewall le plus proche de l extrémité. Ce nom est utilisé pour la seconde partie de l algorithme. 27
2 ème partie de l algorithme : La table «Firewall_clusters» contient la hiérarchie des clusters stockée sous forme de deux champs : 1 - Cluster - Derriere Sur le schéma, CLUSTER_FIREWALL_1 se trouve derrière CLUSTER_FIREWALL_2 qui lui-même se trouve directement relié à la nébuleuse. Cette disposition sera stockée dans la table sous la forme : Premier enregistrement : Cluster : CLUSTER_FIREWALL_1 Derriere : CLUSTER_FIREWALL_2 Second enregistrement : Cluster : CLUSTER_FIREWALL_2 Derriere : null Troisième enregistrement : Cluster : CLUSTER_FIREWALL_18 Derriere : null Lorsque que le champ derriere est à NULL cela signifie que le cluster firewall est directement relié à la nébuleuse. Reprenons notre exemple. La première partie de l algorithme a déterminé que l hôte A est directement relié au cluster CLUSTER_FIREWALL_1. Le programme va maintenant déterminer derrière quel cluster CLUSTER_FIREWALL_1 se trouve. Le programme récupère le cluster déterminé en première partie (CLUSTER_FIREWALL_1) et effectue une requête sur la base de données d Agate-Secure. Tant que le champ derriere ne contient pas NULL (ce qui veut dire qu il n est pas directement relié à la nébuleuse) on continue de faire tourner l algorithme en prenant comme référence le nom du cluster renvoyé par la requête. Dans notre exemple, le premier passage de la requête renvoi CLUSTER_FIREWALL_2. Un second passage est alors effectué avec comme cluster de référence CLUSTER_FIREWALL_2. Ce deuxième passage renvoi NULL. Le programme s arrête alors, il a trouvé tous les clusters séparant l hôte A de la nébuleuse. L algorithme est relancé pour l extrémité suivante, jusqu à ce qu il n y ai plus d extrémités. 1 Si l on regarde la base de données en chapitre 2.3, on remarque un champ de plus : «PolicyFilename», ce dernier est celui d une extension future de l application. 28
Cependant, un cas particulier existe. Imaginons la disposition réseau suivante : Sur le schéma on remarque la présence d un 3 ème hôte. Le chemin utilisé par l hôte A pour communiquer avec l hôte C ne passe pas par la nébuleuse. Dans ce cas, la seconde partie de l algorithme devrait générer un doublon dans la base de données en enregistrant deux fois CLUSTER_FIREWALL_2. Ce doublon est détecté par l algorithme qui ne l enregistre alors pas dans la base de données. 29
4.3.2. Le menu administration 4.3.2.1. Users : Ajouter Ce lien permet à l administrateur d accéder à l interface d ajout d utilisateurs «administrateurs» ou autorisés à accéder aux serveurs de journalisation. Lorsqu il clique dessus le formulaire suivant s affiche. 4.3.2.2. Users : Modifier Ce lien permet à l administrateur de modifier les caractéristiques d un utilisateur, comme son nom, son adresse E-MAIL, son statut d administrateur ainsi que de réinitialiser son mot de passe d accès aux serveurs de journalisation. 4.3.2.3. Users : Supprimer Ce lien permet de supprimer un utilisateur. 30
Cependant, il peut arriver qu il soit impossible de supprimer un utilisateur. En effet, Agate-Secure effectue en premier lieu une vérification. Ainsi, il est d abord obligatoire de supprimer tous les autres droits de l utilisateur. Par exemple, on voit dans la capture ci-dessous que l utilisateur possède des «droits UsersPostes». Cela signifie que l on a assigné à cet utilisateur des postes informatiques. Il faut d abord lui retirer ces postes avant de supprimer son login de la base. 31
Users : Postes users Cette section sert à ajouter l adresse des postes informatiques appartenant aux utilisateurs (entendez «administrateurs sécurité»). Lors du clic, l administrateur est redirigé vers une page listant tous les utilisateurs et tous leurs postes : Plusieurs actions sont possibles : - Ajouter un poste utilisateur - Editer un poste utilisateur - Supprimer un poste utilisateur - Copier les informations dans le presse papier Lors d un ajout, l administrateur doit rentrer 2 informations : - Adresse IP du poste - Nom du poste S il entre l adresse IP, il peut demander au programme de trouver le nom DNS du poste en cliquant sur «trouver le nom». Par ailleurs, s il connait le nom du poste, il peut demander au programme de trouver l adresse IP correspondante en cliquant sur «trouver l adresse IP». Si l administrateur souhaite éditer les postes d un utilisateur en particulier, il peut sélectionner l utilisateur concerné grâce à la liste déroulante en haut à gauche. Une page récapitulative pour cet utilisateur apparaît, donnant accès aux mêmes fonctionnalités précédemment citées : 32
4.3.2.4. Users : Gestion des autorisations Ce lien sert à définir quels utilisateurs ont autorité sur les différents clusters firewalls du réseau (cf. 4.3.1.1). Il est possible de modifier les autorisations par Utilisateur 33
ou bien par cluster. 4.3.2.5. Users : Accès serveur de journalisation Ce lien sert à gérer les autorisations d accès aux serveurs de journalisation par les administrateurs de ces serveur de journalisation car tous les administrateurs non pas tous le droits d accéder aux différents serveurs de journalisation. 34
La page liste tous les serveurs de journalisation inscrits dans la base d Agate-Secure. L administrateur peut autoriser ou non l accès aux serveurs de journalisation à l utilisateur sélectionner en cochant ou décochant les cases correspondantes. Il existe 2 types d accès aux serveurs de journalisation, un accès via SSH, ou bien un accès via un client lourd propriétaire. Une fois les modifications effectuées, l administrateur n a plus qu à cliquer sur «valider» pour que les changements soient enregistrés. 4.3.2.6. Catégorie «Système» Cette catégorie contient plusieurs liens dont l utilité est moindre. L administrateur, via cette section, peut effectuer un «contrôle DB» qui vérifie l intégrité de la base de données d Agate- Secure, se connecter en SSH sur le serveur (le fait de cliquer sur ce lien ouvre une fenêtre putty 2 ci ce dernier est installé sur la machine), ou encore se connecter à PhpMyAdmin qui sert à l administration des bases de données (manipulation de tables, création de bases, etc.). 2 Putty est une implémentation gratuite de telnet et SSH pour Windows et Linux 35
4.3.3. Le menu Gestion de parc 4.3.3.1. Gestion de parc : Liste des firewalls Ce lien permet de lister le parc de firewall, de serveur de journalisation et de serveur de configuration de tout le réseau d Euro-Information. Les équipements sont regroupés par zone, par type et site de production. L administrateur peut cliquer sur le matériel pour éditer sa fiche, pour se connecter en SSH dessus, se connecter à l aide du client lourd SmartView Tracker, pour le pinger, ou encore, pour accéder à ses sauvegardes. A cause de la grandeur du tableau généré par l application (1006x3575 pixels) ainsi que pour des raisons de sécurité (de nombreuses informations sensibles, telles les adresses IP et nom des différents équipements de sécurité apparaissent), il n est pas possible de fournir de capture d écran de cette section. Voyons ce qui se passe lorsque l administrateur édite un type de matériel. 4.3.3.1.1. Edition d un serveur de journalisation Lorsque l on clique sur un serveur de journalisation le formulaire suivant s affiche : On peut changer le serveur de configuration dont dépends le serveur de journalisation, changer l ip du serveur de journalisation, son site géographique, son modèle, etc. On peut, en connaissant le nom, résoudre l ip et inversement. Une fonctionnalité intéressante est la possibilité d obtenir certaines informations directement, à partir du matériel lui-même grâce au protocole SNMP. Pour ce faire, l administrateur doit avoir rentré une adresse IP puis doit cliquer sur «récupérer infos SNMP». Il obtiendra alors un affichage de ce type : 36
On remarque des petites ampoules jaunes derrière certains champs, ces ampoules correspondent à la réponse donnée par le matériel. Les informations récupérées par ce biais sont : - Le nom du serveur de journalisation - La version du logiciel - La taille de la RAM Enfin, on peut tout simplement supprimer le serveur de journalisation. 37
4.3.3.1.2. Edition d un firewall Lorsque l on clique sur un firewall on obtient l affichage suivant : Tout comme pour l édition d un serveur de journalisation, l administrateur a à compléter de nombreux champs. Un firewall étant constitué de plusieurs interfaces, on peut les ajouter en cliquant sur le bouton «ajouter une interface». Une nouvelle ligne en dessous des autres interfaces s ajoute. Si une interface est déjà renseignée, il est possible, comme pour les serveurs serveur de journalisation, de récupérer certaines informations via le protocole SNMP en cliquant sur «Récupérer informations SNMP via l interface d accès sélectionnée». 38
Lorsque que l on clique sur ce bouton le logiciel va récupérer les informations suivantes : - Nom du firewall - Le nom, l adresse IP, le masque de chaque interface configurée sur le firewall - La version du logiciel - La taille de la RAM On remarque qu une section s est ajoutée : «informations SNMP». Cette section contient toutes les interfaces configurées sur le firewall. Si l administrateur le souhaite, il peut les importer dans la fiche du firewall en sélectionnant celles qui l intéresse et en cliquant sur «importer». Une fois toutes les modifications effectuées, il n a plus qu à valider en cliquant sur «modifier». Il peut par ailleurs tout simplement supprimer le firewall en cliquant sur «supprimer». 39
4.3.3.1.3. Modification d un serveur de configuration Si l on clique sur un serveur de configuration le formulaire suivant s affiche : 5. Agate-Secure et la configuration des serveurs de journalisation Nous avons vu en 4.3.2.6 qu il est possible de modifier les droits d accès des administrateurs aux différents serveurs de journalisation. Lorsque l on valide ce formulaire les modifications ne sont pas immédiatement répercutées. Elles sont en réalité simplement stockées dans la base de données d Agate-Secure. C est un script Bash lancé tous les soirs qui va effectuer les répercutions. Deux scripts Bash ont été écrits, le premier script lance le second, le second script et lui-même divisé en plusieurs sous-scripts écrits en syntaxe Expect 3. Nous allons détailler le fonctionnement des scripts. 5.1. Script n 1 Ce script effectue une requête sur la base de données d Agate-Secure et récupère les users et mots de passes nécessaires à la connexion sur les différents serveurs de journalisation. Puis, pour chaque serveur de journalisation récupéré dans la base, le script 1 appelle le script 2 avec en paramètre l adresse du serveur de journalisation, le user et le mot de passe de connexion. 5.2. Script n 2 Ce script se connecte au serveur de journalisation passé en paramètre et récupère grâce à différents scripts Expect les utilisateurs et les postes autorisés à se connecter. Il compare ensuite cette liste d utilisateurs et de postes aux données contenues dans la base. S il existe des utilisateurs ou des postes dans la base qui devraient avoir accès au serveur de journalisation et qui n y ont pas accès, ils sont ajoutés automatiquement sur le serveur grâce à un script Expect. Si le mot de passe d un des utilisateurs a changé dans la base, un script Expect modifie le mot de passe sur le serveur. 3 Expect est un outil pour automatiser des applications interactives comme Telnet, FTP, passwd, fsck, etc. http://wiki.tcl.tk/201 40
S il existe des utilisateurs ou des postes dans la base qui ne devraient pas avoir accès au serveur de journalisation et qu il y ont accès, ils ne sont pas supprimés du serveur, mais sont signalés à l administrateur système. 6. Conclusion Agate-Secure possède de multiples finalités, à la fois gérer les nombreuses demandes d ouverture firewall, mais aussi, par extension, gérer la liste des firewalls et des serveurs de journalisation. Cette application est amenée avec le temps à subir de nombreuses évolutions. 41