Installation mise en œuvre de Sphynx

Transcription

1 Installation mise en œuvre de Sphynx EOLE 2.2 Octobre 2012

2 Version du document Octobre 2012 Date Création 05/02/2008 Editeur Pôle de compétence EOLE Rédacteurs Équipe EOLE Licence Cette documentation, rédigée par le pôle de compétence EOLE, est mise à disposition selon les termes de la licence : Creative Commons Paternité-Pas d'utilisation Commerciale-Partage des Conditions Initiales à l'identique 2.0 france : Vous êtes libres : de reproduire, distribuer et communiquer cette création au public ; de modifier cette création Selon les conditions suivantes : paternité : vous devez citer le nom de l'auteur original de la manière indiquée par l'auteur de l'oeuvre ou le titulaire des droits qui vous confère cette autorisation (mais pas d'une manière qui suggérerait qu'ils vous soutiennent ou approuvent votre utilisation de l'œuvre) ; pas d'utilisation Commerciale : vous n'avez pas le droit d'utiliser cette création à des fins commerciales, y compris comme support de formation ; partage des Conditions Initiales à l'identique : si vous modifiez, transformez ou adaptez cette création, vous n'avez le droit de distribuer la création qui en résulte que sous un contrat identique à celui-ci. A chaque réutilisation ou distribution de cette création, vous devez faire apparaître clairement au public les conditions contractuelles de sa mise à disposition. La meilleure manière de les indiquer est un lien vers cette page web. Chacune de ces conditions peut être levée si vous obtenez l'autorisation du titulaire des droits sur cette œuvre. Rien dans ce contrat ne diminue ou ne restreint le droit moral de l'auteur ou des auteurs. Cette documentation est basée sur une réalisation du pôle EOLE. Les documents d'origines sont disponibles sur le site du pôle. EOLE est un projet libre (Licence GPL). Il est développé par le Pôle de Compétence EOLE du Ministère de l'éducation nationale, rattaché au Centre d'etudes et de Traitements Informatiques de l'académie de Dijon (CETIAD). Pour toute information concernant ce projet vous pouvez nous joindre : Par courrier électronique : eole@ac-dijon.fr Par FAX : Par courrier : EOLE-CETIAD 33 rue Berbisey - B.P DIJON CEDEX le site : 2

3 Sommaire Sommaire I Introduction à Sphynx Qu'est ce que Sphynx? A qui s'adresse-t'il? Les briques logicielles Sphynx... 5 II Résumé des quatre phases...6 III Configuration de la haute disponibilité Sphynx...8 IV Instanciation du Sphynx...12 V L'interface d'administration semi-graphique Présentation Les menus manage-sphynx.sh Initialisation de Sphynx Introduction Utiliser Sphynx en mode PKI Initialisation du serveur en mode PKI Demander un certificat "AGRIATES" à l'autorité de Certification Utiliser Sphynx en mode clef Monter un tunnel Amon-Sphynx Opérations effectuées sur le Sphynx Opérations effectuées sur le pare-feu Amon Recharger la liste des certificats révoqués Renouveler un certificat périmé Administration de la haute disponibilité Mise à jour sur Sphynx VI Documentations techniques Services actifs sur Sphynx Glossaire

4 Introduction à Sphynx I Introduction à Sphynx Le serveur Sphynx est un concentrateur de réseau virtuel privé (RVP * ou VPN). Il permet de relier des stations, des sous-réseaux, ou des réseaux entre eux, au travers d'internet et ce de manière sécurisée. Le serveur Sphynx* fait parti des éléments constitutifs du réseau AGRIATES*. 1 Qu'est ce que Sphynx? Sphynx est un concentrateur de Réseau Virtuel Privé (RVP). Intégrant des composants logiciels de haute disponibilité, Sphynx vous permet de relier en réseau vos serveurs pour former un réseau virtuel privé (RVP) avec le pare-feu Amon dans les établissements distants et Sphynx en entrée de votre réseau académique. Caractéristiques principales : possibilité de travailler en mode PKI (certificats) ou en mode clef (clefs RSA) ; le concentrateur académique Sphynx comprend un pare-feu pour se protéger des attaques ; fait l'objet d'une distribution spécifique ; communications chiffrées entre les réseaux établissements et le réseau académique ; toutes les connexions RVP reviennent sur le Sphynx ; préparation des configurations établissements sur le serveur Sphynx ; mise à jour opérée sur le serveur Sphynx au moyen des outils livrés dans la distribution ; possibilité de haute disponibilité. 2 A qui s'adresse-t'il? Le concentrateur de Réseau virtuel privé Sphynx s'adresse à toutes les structures souhaitant prolonger leur réseau au travers Internet. 4

5 Introduction à Sphynx 3 Les briques logicielles Sphynx Chaque module EOLE est constitué d'un ensemble de briques logicielles. Chacune de ces briques peut évoluer indépendamment des autres et faire l'objet d'une actualisation ou d'une intégration par l'intermédiaire des procédures de mise à jour, afin d'ajouter de nouvelles fonctionnalités ou d'augmenter la sécurité. Briques logicielles communes à tous les modules Noyau Linux 2.6 : Noyau Linux Ubuntu ; OpenSSH (équivalent de telnet chiffré et sécurisé) : demande une authentification sur la machine cible, cet outil permet une prise de main à distance ; Rsyslog : service de journalisation. Il permet également la centralisation des logs ; Pam : Gestion des authentifications ; EAD : l'outil d'administration du serveur ; EOLE-SSO : gestion de l'authentification centralisée ; NUT : gestion des onduleurs ; NTP : synchronisation avec les serveurs de temps. Briques logicielles spécifiques Bind : implémentation la plus répandue du DNS (résolution des noms de machine en adresse IP) ; Iptables : filtrage d'adresses IP ; Strongswan : version libre d'ipsec. Permet la création de réseaux virtuels privés. 5

6 Résumé des quatre phases II Résumé des quatre phases La phase d'installation Pour installer un module, il suffit de : démarrer sur le CD-ROM EOLE ; sélectionner le module à installer parmi ceux proposés ; valider. à la fin de l'installation, cliquer sur continuer, le système redémarre automatiquement ; vous pourrez ouvrir une session avec l'utilisateur "root" et le mot de passe par défaut "eole". La phase de configuration Lancer la commande [gen_config] ou se connecter sur l'application Zéphir, configurer le serveur et enregistrer le serveur. La phase d'instanciation Lancer la commande [instance zephir.eol]. Au premier lancement de l'instanciation, il est nécessaire de modifier les mots de passe : root ; l'utilisateur local à droit restreint (scribe, horus, amonecole,...) ; sur Amon, en cas d'utilisation d'un réseau pédagogique et d'un réseau administratif, le second administrateur amon2 permet d'administrer le réseau pédagogique ; sur AmonEcole, en cas d'utilisation d'un réseau pédagogique et d'un réseau administratif, le second administrateur amonecole2 permet d'administrer le réseau pédagogique ; admin sur Scribe et Horus ; admin_zephir sur Zéphir. Par défaut, le système regarde la pertinence des mots de passe. Pour cela, il utilise un système de "classe de caractères" : les lettres en minuscule [a-z] ; les lettres en majuscule [A-Z] ; les chiffres [0-9] ; les caractères spéciaux (exemple : $*ùµ%, ; :! /.?) ; Il faut utiliser différentes classes de caractères pour que le mot de passe soit considéré comme valide. Par défaut, voici les restrictions : une seule classe de caractères : impossible ; deux classes de caractères : 9 caractères ; trois et quatre classes : 8 caractères. Cette configuration est modifiable durant l'étape de configuration, en mode expert. Attention Il s'agit de comptes d'administration donc sensibles sur le plan de la sécurité. Il est important de renseigner des mots de passe forts. 6

7 Résumé des quatre phases Cet article du CERTA donne une explication détaillée sur la stratégie des mots de passe. La phase d'administration Correspond à l'exploitation du serveur. Chaque module possède des fonctionnalités propres, souvent complémentaires. Diverses interfaces permettent la mise en œuvre de ces fonctionnalités et en facilitent l'usage : l'interface d'administration EOLE : EAD ; l'interface semi-graphique ; divers interface d'administration (Zéphir-web, CUPS, Sympa,...) ; différents outils (Era,...). Il s'agit aussi de gérer les mises à jour. 7

8 Configuration de la haute disponibilité Sphynx III Configuration de la haute disponibilité Sphynx Principe de fonctionnement de la haute disponibilité Sphynx intègre un système permettant la haute disponibilité du service IPsec. Il s'agit de haute disponibilité simple, en mode actif/passif, sans répartition de charge. Cette fonctionnalité de haute disponibilité est assurée par le produit Heartbeat (cf pour plus d'informations). Le principe est le suivant : Principe : plusieurs machines forment un cluster dont chaque machine est un node. Tous les nodes vont vérifier, à intervalle régulier, si les autres répondent en prenant leurs pouls (d'où le nom de heartbeat). Si une machine cesse de fonctionner, les autres prennent le relai pour assurer le service. On accède au cluster au travers d'une seule et unique adresse IP (alors qu'il composé de plusieurs nodes). Dans la configuration de Sphynx, cette adresse se nomme "adresse ip redondé". Etant donnée que Sphynx à deux interface (une externe et une interne), nous aurons besoin d'une adresse redondé pour la patte externe et d'une pour la patte interne. Le schéma suivant montre un exemple de fonctionnement. 8

9 Configuration de la haute disponibilité Sphynx Fig. 1 exemple de fonctionnement de la haute disponibilité sur SphynxNG Tous les Amon se connectent sur le même Sphynx mais via une adresse virtuelle. En cas de défaillance de l'un des deux Sphynx, c'est le second qui prend automatiquement le relai du premier. La configuration de toutes les connexions (comprendre tous les réseaux Amon) se fait à partir du même Sphynx. Elle est ensuite répliquée sur le Sphynx secondaire. Mise en œuvre sur Sphynx Attention Pré requis : 2 serveurs identiques (de préférence). 1 maître et 1 esclave ; 3 cartes réseaux par machine ; 1 câble croisé pour relier les eth2 des 2 machines ; 1 adresses IP par interface pour chacune des machines plus 1 IP supplémentaire pour eth0 et eth1 (IP virtuelle). La configuration se passe uniquement au moment du gen_config. Dans l'onglet "Général", à la question "Activation de la haute disponibilité oui/non", choisir si votre Sphynx sera le maître ou l'esclave. En fonction de ce choix, un nouvel onglet apparaîtra haute_dispo_maitre si choix "maitre" haute_dispo_esclave si choix "esclave" Dans l'onglet correspondant, il faut renseigner les différents champs (adresses IP, nom, etc) 9

10 Configuration de la haute disponibilité Sphynx Écran 1 Configuration de la haute disponibilité dans gen_config 10

11 Configuration de la haute disponibilité Sphynx Explications concernant les paramètres du dictionnaire : adresse ip, network, netmask et broadcast eth2 -> les deux serveurs sont reliés entre eux par un câble croisé via une interface réseau ethernet. Les adresses à renseigner ici sont des adresses d'un réseau privé (RFC1918), non utilisé, afin que les 2 machines puissent échanger leurs "pouls". Il faut 2 adresses (une pour chacune des machine). nom_machine_maitre ou nom_machine_esclave -> heartbeat a besoin d'un nom différent pour chacune des deux machines. Il faut donc leur en trouver un (il sera ajouté dans le fichier hosts). adresse_ip_esclave_eth2 ou adresse_ip_maitre_eth2 -> adresse ip donnée à l'autre machine (sur l'interface eth2 -> interface heartbeat) adresse_ip_esclave_eth0 ou adresse_ip_maitre_eth0 -> adresse ip publique de l'autre sphynx (de l'esclave si on se trouve sur le maître et du maître si on se trouve sur l'esclave). adresse_ip_redondee_eth0 -> adresse publique virtuelle. Ce paramètre doit être identique sur les deux machines. Il faut mettre une adresse non utilisé par aucune machine sur ce réseau. C'est l'adresse qui sera connue des clients. adresse_ip_redondee_eth1 -> adresse virtuelle du réseau interconnecté sur la patte interne des sphynx. Ce paramètre doit être identique sur les deux machines. Il faut mettre une adresse non utilisé par aucune machine sur ce réseau. C'est l'adresse qui sera utilisée par les sphynx pour accéder aux différents réseaux privées. mail_to -> adresse mail sur laquelle envoyer les alertes passerelle_smtp -> comme son nom l'indique. Il faut que les sphynx puissent poster les mails quelque part. Les autres paramètres sont à laisser par défaut, sauf si vous savez ce que vous faites... Attention Si vous avez déjà une base initialisée (sur un serveur déjà instancié) et que vous souhaitez mettre en place de la haute disponibilité, il y a une opération manuelle à faire. Certaines informations doivent être mise à jour dans la base. Il faut exécuter un script qui se chargera de cette action (après avoir réinstancier le serveur). /usr/share/eole/sphynx-vpn/tunnel/haute_dispo A partir de la Version 2.2 de Sphynx, le système de gestion de la haute disponibilité a quelque peu évolué (et changé). Il faut obligatoirement relancer la procédure d'instanciation pour que les nouveaux paramètres soient mis en place et pour que la haute disponibilité fonctionne. Voir aussi... 11

12 Instanciation du Sphynx IV Instanciation du Sphynx L'instanciation de Sphynx permet de renseigner les mots de passe des utilisateurs sphynx et de root. 12

13 V Administration de Sphynx 1 L'interface d'administration semigraphique 1.1. Présentation Une interface semi-graphique est également disponible sur quelques modules. L'interface semi-graphique n'est pas présente sur tous les modules. Seulement sur les modules Amon/AmonEcole, Scribe, Horus et Sphynx (grâce au script manage-sphynx lancé en root). Cette interface permet d'exécuter quelques tâches simple d'administration du serveur : diagnostique, mise à jour, liste des paquets en mise à jour, etc Les menus manage-sphynx.sh Toute la gestion des tunnels entre les Amon et le Sphynx est prise en charge par le script manage-sphynx.sh de l'interface semi-graphique. Cette interface permet de gérer toutes les tâches ayant un rapport avec le RVP (coté Sphynx et coté Amon), et celles ayant trait aux tâches simple d'administration du serveur : (diagnostic, mise à jour,test paquets en mise à jour, etc...). 13

14 Écran 2 manage-sphynx Le menu Admin_Serveur permet d'activer la partie administration du serveur, les autres menus correspondent à la gestion du réseau virtuel privé (RVP). 14

15 2 Initialisation de Sphynx 2.1. Introduction Pour initialiser le serveur : se connecter "root" ; lancer le script shell [init-sphynx.sh]. Ce script initialise certaines réponses à partir du fichier de configuration [/etc/eole/config.eol]. Le mode de fonctionnement du Sphynx est donné par le paramètre vpn_mode du menu vpn_pki de l'interface de configuration (PKI ou clef). Un serveur Sphynx en mode clef est plus simple à utiliser puisque l'on s'affranchit de toute la procédure d'obtention de certificats. L'accent sera mis sur le mode certificat, mais les procédures seront quasi identiques en mode clef Sphynx en mode PKI ou en mode clef Le Réseau virtuel Privé (RVP) est prévu pour fonctionner dans les deux modes suivants : mode clef ; mode PKI. Le mode de fonctionnement est lié au concentrateur (serveur Sphynx), celui-ci sera initialisé dans le mode de fonctionnement choisi. Les établissements faisant partie du réseau AGRIATES * doivent être initialisés en mode PKI. Attention Le script init-sphynx.sh permet de supprimer et de réinitialiser un serveur Sphynx dans l'un ou l'autre mode. Dans ce cas la base XML des établissements est remise à blanc! 15

16 Les connexions établissements arrivant sur ce serveur seront dans le même mode que le serveur. Il n'est pas possible de mixer deux modes de connexion sur un Sphynx. Il faut dans ce cas monter un autre serveur Sphynx. Par contre, il est possible d'utiliser un Amon avec deux tunnels de types différents, l'un en mode clef, l'autre en mode PKI et faire arriver un tunnel sur un serveur Sphynx académique configuré en mode clef, et l'autre tunnel sur un autre serveur Sphynx académique configuré lui en mode PKI. Le fonctionnement du concentrateur Sphynx en mode PKI nécessite comme pré-requis, un certificat délivré par l'autorité de certification (CA). Toute la gestion des certificats et des clefs nécessite une infrastructure type RACINE (chaque configuration établissement devant obtenir également un certificat). Les éléments d'un Réseau Virtuel Privé Le concentrateur Sphynx : Il permet la concentration des tunnels en provenance des établissements extérieurs (topologie en étoile) avant de les rediriger vers le sous réseau de concentration choisi ; les réseaux de concentration : derrière le Sphynx (zone sécurisée) il est possible de déclarer et d'atteindre plusieurs sous réseaux de concentration ; la connexion ou tunnel : connexion au travers l'internet permettant de relier deux points d'une manière sécurisée (tunnel chiffré) ; Le pare-feu Amon : point d'entrée dans le réseau établissement et point de sortie unique de l'établissement vers Internet (une extrémité du tunnel RVP) ; Le réseau établissement : situé derrière le pare-feu Amon, il est composé de plusieurs sous-réseau composés eux mêmes de stations. Le RVP (Réseau virtuel privé) permet de relier ces sous-réseaux et/ou les stations aux réseau de concentration derrière le Sphynx. La création de ce RVP permet donc de relier l'établissement à un ou plusieurs sous-réseaux des services académiques. Il est possible de choisir à l'intérieur de l'établissement la station, les stations du sous-réseau, le(s) sous-réseau(x) pouvant transiter au travers du tunnel ou des tunnels, et ainsi bénéficier des avantages du RVP (chiffrement des informations). Le schéma ci-dessous récapitule de manière simple les différents composants d'un Réseau virtuel privé. 16

17 Fig. 2 test Les serveurs impactés Pour monter un tunnel vous devez intervenir sur les serveurs suivant : Sphynx, Amon, Zéphir (pour les utilisateurs du gestionnaire de parc). Vous devez également connaitre les éléments des réseaux à relier. C'est à dire : coté Amon : la station, le sous-réseau ou le réseau de l'établissement à translater dans le tunnel. Coté Sphynx : le sous-réseau de concentration à atteindre. Le Sphynx intègre une fonctionnalité de pare-feu Le serveur Sphynx, concentrateur académique, intègre un module pare-feu lui permettant de filtrer dynamiquement les établissements et de n'accepter que ceux connus dans la base XML des établissements. Le module pare-feu permet donc au concentrateur Sphynx de se protéger lui même. Les connections ou tunnels L'Amon accepte de monter de 1 à n tunnels vers 1 ou n Sphynx. On peut donc envisager, par exemple, d'avoir dans un établissement un tunnel vers un Sphynx académique en mode PKI protégeant les flux administratifs et un tunnel faisant transiter certains flux pédagogiques ou autres vers un concentrateur Sphynx mode clef dédié à ces flux. Les tunnels sont montés de façon permanente, une vérification automatique depuis l'extrémité établissement est mise en place. Elle permet de remonter le tunnel en cas de problème. Depuis l'extrémité concentrateur Sphynx une réinitialisation générale est activée tous les matins à 7 heures. 17

18 Fig. 3 Relations Amon et Sphynx par les tunnels Matérialisation ou dématérialisation du certificat Il s'agit en fait de connaitre, d'une part, où sont stockés les fichiers de certificats nécessaires et, d'autre part, de déterminer par quel moyen faire parvenir ces fichiers à l'extrémité Amon du tunnel pour sa configuration. Dans la première version Sphynx, seul le support disquette était implémenté, le transfert des fichiers nécessaires au RVP se faisant par l'intermédiaire de disquette. Il est maintenant possible de gérer la configuration RVP établissement au moyen du serveur Zéphir. Celui-ci peut, à la demande, délivrer la configuration à l'amon de l'établissement pour installer un RVP. Avant de choisir vous devez répondre à la question : où se trouvent mes fichiers de configuration RVP? sur une disquette ; sur le répertoire /home/data du disque local Sphynx ; sur le serveur Zéphir, pour les administrateurs utilisant le gestionnaire de parc. Dans le dernier cas, les serveurs Sphynx et Amon doivent être répertoriés sur le Zéphir dans la suite du document nous utiliserons la solution échange par disquette Utiliser Sphynx en mode PKI Initialisation du serveur en mode PKI Le schéma suivant montre l'enchainement des questions pour une initialisation en mode PKI : 18

19 Fig. 4 Schéma d'utilisation d'un Sphynx en mode PKI 19

20 Nous sommes en mode PKI, il faut donner le CN du certificat : Donner l'identifiant de ce serveur (CN du certificat) Exemple : A Sélectionner le support choisi : la disquette ou le répertoire contenant les fichiers pkcs7 et la clef privée : Quel est le support des fichiers de configuration : disquette ou répertoire Les messages suivants apparaissent : Initialisation SPHYNX Mode pki activé extraction des certificats Donner la phrase secrète associée à la clef privée Donner la passphrase associée à la clef prive Si tout est correct, vous devez valider ou ressaisir les informations suivantes (certaines sont déjà initialisées aux valeurs du fichier de configuration.eol) : Adresse IP externe de votre serveur Adresse IP du routeur Internet Adresse réseau du réseau de concentration Masque de réseau de concentration Après avoir renseigné et validé les paramètres ci-dessus, le message suivant apparait : Première initialisation... Lorsque le traitement est terminé, le message suivant apparaît : Initialisation du SPHYNX Création de la base de configuration FREESWAN Configuration terminée Le résultat de l'opération d'initialisation est stocké dans le fichier sphynx.xml dont voici un extrait ci-dessous: <?xml version="1.0" encoding="iso "?> <!DOCTYPE sphynx PUBLIC " //Eole//DTD eole sphynx V1.0//FR" "/usr/sha <sphynx nom="/c=fr/o=gouv/ou=education/ou=ac dij/cn= g 88" id=" <academie> <clef rsa/> <clef publique/> <reseau_sphynx id="sphynx 0" nom="default"> <right> </right> <rightsubnet> / </rightsubnet> <rightnexthop> </rightnexthop> </reseau_sphynx> </academie> </sphynx> Il contient les données et la clef académique, mais encore aucune information concernant les établissements. A ce stade, il est possible de créer des configurations RVP pour les établissements. 20

21 Demander un certificat "AGRIATES" à l'autorité de Certification Cette demande s'effectue en mode "décentralisé" sur le Sphynx par l'intermédiaire du menu manage-sphynx. Cette opération fait référence au document PC RACINE-AGRIATES (politique de certification). lancer le menu demande de certificat ; sélectionner le support de réception des fichiers générés. disquette, /home/data sur Sphynx ; donner l'identifiant du serveur auquel est destiné le certificat (CN) ; saisir un commentaire pour le certificat demandé ; après la génération de la clef (2048 bit), entrer et confirmer un mot de passe. A l'issu de l'opération deux fichiers sont générés : identifiant-etab.p10 contiennant la demande de certificat (CSR), ce fichier doit être transmis à l'autorité de certification (AC) à Toulouse ; privkey.pem contiennant la clef privée du serveur à qui est destiné le certificat. Transmission du CSR Seule le fichier.p10 sera transmit à l'autorité de certification (l'ac), la clef privée elle, n'est pas transmise Utiliser Sphynx en mode clef Le schéma suivant montre l'enchaînement des questions pour une initialisation en mode clef : 21

22 Fig. 5 schéma sphynx en mode clef Nom DNS du serveur SPHYNX Adresse IP externe de votre serveur Adresse IP du routeur Internet Adresse réseau du réseau de concentration Masque de réseau de concentration Après avoir renseigné et validé les paramètres ci-dessus, le message suivant apparait : Première initialisation Génération de la clef... Veuillez patienter... La génération de la clef (spécifications AGRIATES longueur 2048) peut prendre quelques instants. Lorsque le traitement est terminé, le message suivant apparaît : Initialisation du Sphynx Création de la base de configuration FREESWAN Configuration terminée Le résultat de l'opération d'initialisation est stocké dans le fichier sphynx.xml, il contient les données de l'académie et la clef académique, mais aucune information concernant les établissements. A ce stade, il est maintenant possible de créer des configurations RVP pour les établissements. 22

23 Attention Si la base sphynx.xml existe déjà sur le serveur, un message d'avertissement est affiché. Vous pouvez abandonner le traitement par la touche [ESC] ou continuer en écrasant l'ancienne configuration. Toutes les configurations seront perdues. S'il s'agit d'une erreur, il est possible de récupérer le fichier sphynx.xml en recopiant la sauvegarde sphynx.xml.sav sur sphynx.xml (dans /usr/share/eole/sphynx.vpn/xml) Monter un tunnel Amon-Sphynx Opérations effectuées sur le Sphynx Attention Pré-requis : posséder les fichiers nécessaires (issus de l'autorité de certification) certif.pkcs7 etab.pem ; connaitre les paramètres de la machine Amon ou bien avoir recopié sur la disquette du certificat le fichier de configuration Amon de l'établissement config.eol (si tel est le cas, le programme initialisera les paramètres demandés avec les valeurs du fichier de configuration) ; connaitre les éléments de l'établissement à tunnéliser (réseaux, sous-réseaux, stations). Pour ajouter un établissement valider l'item du menu : Gérer l'amon établissement puis Ajouter l'amon et répondez aux questions : Support des fichiers de configuration Attention Vous disposez de 3 choix : la disquette sur laquelle sont stockés les fichiers de configuration nécessaires ; un répertoire sur le disque local (/home/data) sur lequel vous avez recopié les fichiers nécessaires (idem que disquette) ; le serveur Zéphir : avant d'utiliser ce choix vous devez avoir recopié sur le répertoire /home/data les fichiers nécessaires concernant cet établissement. A la fin du traitement les fichiers de configuration seront transférés automatiquement sur le serveur Zéphir et seront donc disponibles pour une configuration ultérieure du tunnel sur l'amon. Pré-requis : le concentrateur Sphynx et le serveur Amon doivent être enregistrés sur le Zéphir au préalable. Donner l'identifiant du serveur Amon (le CN du certificat) Le programme initialise un client RVP pour l'établissement considéré et demande la disquette contenant le certificat préalablement généré : Insérer la disquette contenant le fichier pkcs7 et la clef privée Attention Cette disquette servira ultérieurement à la configuration RVP du serveur Amon dans l'établissement, elle sera demandée au moment de la configuration du pare-feu. Elle contiendra le certificat de l'établissement ainsi que les éléments nécessaires à la configuration du RVP. 23

24 Vous devrez répondre alors aux questions suivantes concernant le réseau de l'établissement. Il est préférable de préparer le travail avant saisie et surtout d'avoir une idée claire de la partie du réseau établissement qui doit emprunter le tunnel : Nom de l'établissement C'est une étiquette (information libre) Index passerelle nom DNS Amon Adresse IP externe du serveur Amon correspond à la valeur eth0 du fichier de configuration Amon. Adresse IP du routeur Adresse réseau entrant dans le tunnel Masque réseau entrant dans le tunnel Adresse de translation du pare feu dans le tunnel Attention Cette information est indispensable. Lui donner une adresse IP libre du réseau entrant dans le tunnel (paramètre précédent). Ce paramètre est un artifice permettant au pare-feu de rentrer lui même dans le tunnel. Translation dans le tunnel Vous devez d'abord déterminer ce que vous souhaitez faire transiter par le tunnel : une station particulière, une partie de sous-réseau ou un sous réseau entier. Puis si : Le réseau entrant dans le tunnel est dans un plan d'adressage académique/national : les adresses réseaux établissement sont uniques et donc clairement identifiables en sortie de tunnel (coté Sphynx), vous n'avez pas besoin de translater les adresses (ne pas renseigner) Le réseau entrant dans le tunnel n'est pas dans un plan d'adressage académique/national (exemple pour un sous réseau administratif en ), ce réseau ne pourra pas être clairement identifié en sortie de tunnel (coté Sphynx, risque de redondance), Il est indispensable de transformer cette adresse (ex : ) en lui donnant une adresse de translation dans le tunnel. Après saisie des informations, un écran récapitule les informations enregistrées. Vous pouvez abandonner ou valider. L'ajout d'un établissement dans la base sphynx.xml met automatiquement à jour le fichier bastion.xml (protection de la machine par les règles du pare-feu). Seul l'accès des établissements dont l'adresse IP est connue sera autorisé sur le Sphynx. Remarque Contenu de la disquette générée pour l'établissement : fichier Id : il contient l'identifiant de l'établissement ; fichier ipsec.conf_identifiant établissement : ce fichier contient la configuration RVP établissement et les clefs publiques ; fichier ipsec.secrets_identifiant établissement : ce fichier contient la clef privée de l'établissement. Elle sera stockée sur l'amon. Fichier ipsec.updown_sphynx_identifiant établissement : contient les règles de routage à appliquer aux extrémités du tunnel ; fichier test-rvp : contient un script shell destiné à tester le tunnel lorsqu'il est monté ; fichier certif.pkcs7 : contient le certificat délivré par l'ac (autorité de certification) ; fichier privkey.pem : contient la clef privée de l'établissement ; fichier etab.eol : contient le fichier de configuration établissement. 24

25 Opérations effectuées sur le pare-feu Amon Le Réseau Virtuel Privé * peut être monté au moment de l'installation du serveur Amon (procédure d'instanciation) ou installé sur un Amon déjà en exploitation (mais avec le RVP non configuré). Opération à l'installation du serveur Au lancement de la première instanciation instance zephir.eol Voulez vous configurer le réseau virtuel privé maintenant (oui,non) attention vous aurez besoin de la disquette contenant les fichiers de configuration vous devez répondre oui à cette question Activation de la fonction réseau virtuel privé insérez votre disquette de configuration tapez [ENTREE] Les informations sont lues, la configuration RVP est mise en place... entrez le mot de passe de la clef privée Si le mot de passe est correct le RVP est configuré pour cette machine et l'instanciation peut se poursuivre... Opération sur un Amon en exploitation Il suffit de lancer sous le login "root" le script : active_rvp.sh et répondre aux questions posées. Attention Pré-requis : vous devez disposer des fichiers certif.pkcs7 et clef privée 2.5. Recharger la liste des certificats révoqués Rechargement automatique de la liste des certificats révoqués Au cours de sa durée de vie (5 ans pour le certificat RACINE-AGRIATES), ce certificat peut être révoqué. La liste des certificats révoqués (LCR) est mise à disposition par l'autorité de certification de Toulouse. Elle est rechargé automatiquement toutes les 7 heures par les concentrateurs Sphynx. Rechargement manuel de la liste des certificats révoqués Dans certain cas, il peut être nécessaire de recharger la LCR en urgence sans attendre ce délai de 7 heures. Cette opération s'effectue en utilisant le menu de manage-sphynx.sh : recharger la LCR Il y a tentative de récupération de la dernière LCR sur les 2 sites web connus. Si la liste de l'ac est plus à jour que celle du concentrateur Sphynx, elle est téléchargée et remplacée. 25

26 Écran 3 Liste des certificats révoqués On s'aperçoit sur l'écran ci-dessus que les deux URL sont testées l'une après l'autre. Dans ce cas la liste de Toulouse n'est pas plus à jour que celle du concentrateur Sphynx, il n'y a donc pas de mise à jour. On peut vérifier en mode commande l'état de la LCR du Sphynx : #ipsec listcrls Écran 4 Résultat de la commande ipsec listcrls 2.6. Renouveler un certificat périmé 26

27 Durée de vie d'un certificat RACINE-AGRIATES Les certificats AGRIATES sont utilisés par les serveurs Sphynx et Amon. Ces certificats délivrés par l'ac (autorité de certification) ont une durée de vie de 5 ans. Lorsqu'un certificat arrive en fin de vie, il est révoqué et il apparait dans la LCR (liste des certificats révoqués). Un agent Zéphir spécifique à été créé pour alerter l'administrateur que le certificat du serveur va bientôt être révoqué : 45 jours avant, avertissement, l'agent apparait en orange ; 30 jours avant, alerte, l'agent apparait en rouge. Les agents Zéphir sont accessibles depuis le serveur Zéphir ou depuis l'ead du serveur Amon ou Sphynx. La procédure Il faut faire une nouvelle demande de certificat, dans manage-sphynx.sh : Demander_Certificat. Il est impératif de garder le même CN que celui de la machine actuelle. Puis suivre la procédure habituelle pour effectuer la demande de certificats. Une fois le certificat récupéré sur l'ac, il suffit de le faire prendre en compte sur votre Sphynx. Dans managesphynx.sh : gestion_conf_sphynx/remplacement_certif. Il est possible de vérifier les dates du nouveau certificat en mode ligne de commande : cd /etc/freeswann/ipsec.d/certs openssl x509 in sphynx.pem noout dates Le résultat obtenu est de la forme : notbefore=apr 5 14:22: GMT notafter=apr 4 14:22: GMT 3 Administration de la haute disponibilité Principe de fonctionnement sur Sphynx Les opérations d'ajout, modifications, etc. des établissements doit se faire de préférence sur le Sphynx maitre. A chaque fois qu'une modification de la base (ajout ou suppression d'un établissement, ajout de tunnels,...) est effectué avec l'outil manage-sphynx, ces modifications sont reportées sur le Sphynx secondaire. Cette procédure s'effectue au travers d'un script (/usr/share/eole/synchro-sphynx.sh). Ce script recopie l'ensemble des données (base xml, fichiers de configurations se trouvant dans /etc/freeswan et dans /usr/share/eole/sphynx-vpn ainsi que les fichiers se trouvant dans /home/data). Toute la partie gestion de la haute disponibilité à proprement parlé (assignation des ressources, lancement des services...) est géré par Heartbeat. Sur les versions < à la version 2.2 stable, la surveillance était effectué par un service spécifique (mon) qui se chargeait de tester si IPsec fonctionnait. A partir de la 2.2, ce service n'est plus utilisé. Tout a été intégré au niveau de Heartbeat. Gestion et administration du cluster Un outil graphique permet de configurer, d'administrer et de monitorer le Cluster. Il se lance par la commande hb_gui. Pour accéder à cet outil, il faut se connecter en ssh (avec l'option -X) sur un des Sphynx (celui qui est actif). Pour contrôler l'existence du service sur le serveur, vérifier que le port 5560 est ouvert (avec la commande netstat -ntl). 27

28 Écran 5 Haute disponibilité : écran d'accueil de l'interface Il faut se logger pour accéder au cluster. Pour cela, il suffit de cliquer sur le bouton le plus à gauche ou bien aller dans le menu "connection", "login". 28

29 Écran 6 Haute disponibilité : se connecter L'utilisateur permettant l'accès à la console est l'utilisateur Sphynx 29

30 Écran 7 Haute disponibilité : accès à la console Sphynx L'interface une fois loggé... Elle donne accès à l'ensemble des ressources et aux paramètres du cluster. 30

31 Écran 8 Haute disponibilité : les ressources Relancement du RVP Lors de l'utilisation de la haute disponibilité, il faut utiliser le script d'initialisation "ipsecsphynx" en lieu et place du script "ipsec" pour relancer le RVP. Sinon, la détection du bon fonctionnement du RVP par HeartBeat sera défaillante et les tunnels basculeront sur l'autre noeud. Voir aussi... > cf "Configuration de la haute disponibilité Sphynx", page

32 4 Mise à jour sur Sphynx La mise à jour automatique est désactivée sur les Sphynx lorsque ceux ci sont configuré pour fonctionner en haute disponibilité. Il convient de faire régulièrement les mises à jour à la main en utilisant la commande MajAuto puis reconfigure. Mode opératoire pour mettre à jour les Sphynx : commencer par mettre à jour le Sphynx qui n'est pas actif et vérifier qu'elle ne pose pas de problème ; avant de mettre à jour la machine qui est active, passez la seconde en "stand bye" en utilisant l'outil graphique de gestion du cluster si vous ne voulez pas que la bascule des tunnels s'opère ; vous pouvez ensuite mettre à jour la seconde machine. Voir aussi... > cf "Configuration de la haute disponibilité Sphynx", page

33 Documentations techniques VI Documentations techniques 1 Services actifs sur Sphynx Niveaux de fonctionnement La distribution Ubuntu, ne fait pas de distinction entre les runlevels de niveau 2 à 5. 0 : Arrêt 1 : Mode maintenance 2 à 5 : Mode multi-utilisateur complet avec serveur graphique si installé. 6 : Redémarrage Services communs à tous les modules atd bastion cron ead-server ead-web (optionnel) eole-sso (optionnel) gpm mdadm ntp nut rc.local rmnologin rng-tools rsync rsyslog ssh stunnel4 ulogd usplash z_stats (sauf Zéphir) Services spécifiques heartbeat (optionnel) ipsecsphynx pcscd 33

34 Documentations techniques quagga (optionnel) 34

35 Glossaire Glossaire Qualité de service Régulation des flux du trafic sur un réseau, définition de Wikpedia Réseau AGRIATES RACINE-AGRIATES fait partie du projet réseau RACINE, dont l'objectif consiste à fournir un support sécurisé pour les échanges d'information (ou Réseau Virtuel Privé (RVP)) entre entités du ministère en s'appuyant sur des infrastuctures réseau ouvertes. RACINE-AGRIATES a ainsi pour objectif la fourniture d'un support sécurisé pour les échanges d'information (RVP) entre le réseau de l'administration des établissements et leur rectorat de rattachement. AGRIATES : Accès Généralisé aux Réseaux Internet Académiques et Territoriaux pour les Etablissements Scolaires. RACINE-AGRIATES rassemble dans une même "zone de confiance" académique les établissements scolaires et les services académiques. Ce nouveau réseau privé virtuel sécurisé est l'intranet académique. RVP Réseau virtuel Privé Le réseau virtuel privé permet de relier au travers internet des sous réseaux entre eux. 35