[MIR LINUX] 10/01/2011 ERE P43. Teneur Jérôme Gayral Bastien Promé Rudy Desseaux Vincent Hamon Arnaud Delahaie Jérôme

Transcription

1 10/01/2011 ERE P43 Teneur Jérôme Gayral Bastien Promé Rudy Desseaux Vincent Hamon Arnaud Delahaie Jérôme Groupe [MIR LINUX] Ce rapport portera sur l infrastructure du système d information d Aristote dans une configuration Linux. L étude. L étude détaillera les choix et préconisations technologiques ainsi que la configuration des éléments afin de répondre aux besoins exprimés.

2 Version du document Version Modifications apportées Date 1.0 Première version du document 20/12/ Ajustement entre partie pour cohérence 28/12/ Correction orthographe 3/01/ Refonte de la mise en page 8/01/2011 Equipe MediaNetwork - Teneur Jérôme (Chef de projet) - Gayral Bastien - Promé Rudy - Desseaux Vincent - Hamon Arnaud - Delahaie Jérôme Introduction (Jérôme TENEUR) 2

3 Sommaire 1. Introduction (Jérôme TENEUR) Organisation et gestion des comptes utilisateurs (Jérôme Teneur) Rappel du cahier des charges Choix d une solution Comparatif des solutions existantes Solution retenue Implémentation de LDAP dans l architecture d Aristote DIT LDAP Besoins et ressources Configuration des serveurs Administration de l annuaire LDAP Configuration des clients Conclusion Le serveur de configuration IP (Vincent Desseaux) Rappel des besoins Introductions Présentation du plan d adressage employé Présentation du service DHCP Autres fonctionnalités lié à DHCP Le relai DHCP La haute disponibilité et la répartition de charge La mise à jour dynamique des entrées DNS Intégration du service dans le système d information Définition des paramètres communs à mettre en place pour Aristote Relais DHCP Schéma de l architecture DHCP à mettre en place Les pré-requis et coûts de la solution Les pré-requis Coûts de déploiement Coûts lié à l administration Résolution de noms IP (Rudy Promé) Rappel des besoins Solution que nous proposons Introduction (Jérôme TENEUR) 3

4 1. Bind Le nom de domaine Implémentation de Bind9 (Serveur Maître) Installation Configuration Les enregistrements dynamiques Implémentation des serveurs Esclaves Haute disponibilité pour le siège Les sites distants Les postes clients Supervision des serveurs Schéma physique de l architecture DNS Coûts Coûts matériels Coûts humains Conclusion Maquette Le serveur de ressources (Jérôme Delahaie) Rappel du besoin : Solutions existantes : L appliance matérielle : L appliance logicielle : Serveur Linux ou Unix Solution retenue Architecture proposée Besoins par sites Analyse de l usage Solutions face aux contraintes : Coûts Système de sauvegarde (Arnaud Hamon) Rappel des besoins Comparatif Solution retenue Architecture de fonctionnement Introduction (Jérôme TENEUR) 4

5 2. Backkuppc Gestion de la taille du lieu de sauvegarde Gestion du temps de restauration des fichiers Coûts Le serveur web et l'accès internet sécurisé (Bastien Gayral) Rappel des besoins Objectif Exigences et option Serveur Web Présentation Les logiciels de serveur HTTP Architecture du serveur web Accès public Accès privé (Intranet) Accès internet sécurisé Introduction Présentation Fonctionnement Proxy cache Implémentation du proxy Installation et configuration Conclusion Mise en place d un Firewall avec Netfilter/Iptables (Vincent Desseaux) Serveur VPN (Bastien Gayral) Introduction Présentation Solutions VPN existantes Implémentation de VPN dans l architecture d Aristote Création des certificats et des clés Configuration du serveur VPN Conclusion Outil de monitoring système et réseau (Arnaud Hamon) Infrastructure global (Jérôme TENEUR) Conclusion (Jérôme TENEUR) Introduction (Jérôme TENEUR) 5

6 13. Bibliographie Lexique Annexes Organisation et gestion des comptes utilisateurs (Jérôme Teneur) Choix de l environnement graphique Mise à jour de l annuaire Tests de l annuaire Kerberos Liste partielle des attributs LDAP de la classe «organization» Liste partielle des attributs LDAP de la classe «inetorgperson» Script création utilisateurs Configuration des clients LDAP Configuration pour le montage des répertoires personnels Récapitulatif des réseaux de chaque site à mettre en place (Vincent Desseaux) Plan d adressage des sous réseaux par site Configuration d un serveur DHCP (Vincent Desseaux) Configuration du canal failover du site d Orsay : Mise en place de la fonctionnalité de mise à jour du DNS Les aspects sur la sécurité Déroulement du service DHCP Relais DHCP Fichiers de configuration dhcpd.master.orsay Configuration du DNS BIND9 (Rudy Promé) Configuration serveur Maître Configuration serveur Esclave Phases de tests DNS Configuration matérielle des serveurs de fichiers (Jérôme Delahaie) Serveur de sauvegarde (Arnaud Hamon) Configuration du serveur Squid (fichier server.conf) (Bastien Gayral) Commande Iptables (Vincent Desseaux) Règle de filtrage (Vincent Desseaux) Mise en place d un serveur Nagios sur une Debian (Arnaud Hamon) Mise ne place de PnP4Nagios Introduction (Jérôme TENEUR) 6

7 Table des figures Figure 1 - Carte géographique...8 Figure 2 - DIT LDAP...11 Figure 3 - Besoins Aristote...12 Figure 4 - Réplication et cluster LDAP...17 Figure 5 - Architecture DHCP...24 Figure 6 : Schéma infrastructure DNS...28 Figure 7 - Schéma de synthèse LVM...33 Figure 8 - Implémentation serveur de backup...36 Figure 9 - fonctionnement des sauvegardes...39 Figure 10 : Source Netcraft Figure 11: Implémentation du serveur web...43 Figure 12 : Implémentation des proxys Squid...45 Figure 13 : Implémentation du serveur VPN...49 Figure 14 - Graphique NAgios...51 Introduction (Jérôme TENEUR) 7

8 1. Introduction (Jérôme TENEUR) MediaNetwork a en charge la mise en place d un système d information complet sous environnement Linux/Unix pour le groupe Aristote. Le but de ce projet (dont le chef est Jérôme Teneur) est de disposer, à terme, d une infrastructure cohérente, en environnement linux, couvrant l ensemble des besoins exprimés par le groupe Aristote : - L organisation et la gestion des comptes utilisateurs (Jérôme T.) - Le serveur de configuration IP. (Vincent) - La résolution de noms IP (Rudy) - Le serveur de ressources (Jérôme D.) - Le serveur de sauvegarde (Arnaud) - Le serveur web et l'accès internet sécurisé (Bastien et Rudy) Aussi, au travers de notre expertise, nous préconiserons l intégration de nouveaux éléments dans le système d information d écoulant des besoins exprimés : - Firewall (Vincent) - Serveur VPN (Bastien et Rudy) - Monitoring et gestion des incidents (Arnaud) - Présentation de l infrastructure globale (Jérôme T.) - Virtualisation sous ESX (Arnaud & Jérôme D.) L étude recouvrira les sites d Orsay, Bayonne, Bruxelles et Sophia Antipolis ayant respectivement 400, 180, 160 et 80 postes clients (820 en tout). Figure 1 - Carte géographique Enfin, notons que nous utiliserons la distribution Ubuntu pour les utilisateurs et une distribution Debian pour les serveurs. Introduction (Jérôme TENEUR) 8

9 2. Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 1. Rappel du cahier des charges Le cahier des charges exprime les besoins suivants : L architecture de l annuaire doit s articuler autour d unités organisationnelle par service. Il nous est demandé dans un second temps de mettre en place un outil facilitant la gestion des utilisateurs en s appuyant sur une interface graphique. De plus l importation des utilisateurs et des groupes devra pouvoir se faire via un fichier texte associé à un script automatisé pour inclure de nouveaux utilisateurs. Enfin les utilisateurs devront pouvoir changer de mot de passe aisément. 2. Choix d une solution 1. Comparatif des solutions existantes Dans le monde du libre, deux grandes solutions sont mises en avant : NIS et OpenLDAP. Toutes les deux sont des annuaires permettant de gérer les utilisateurs de manière centralisée. Une autre solution consiste à s appuyer sur une base de données pour gérer les utilisateurs. NIS Network Information Service (NIS) (anciennement Yellow Pages) est un système client-serveur permettant de centraliser les principaux fichiers d administration situés dans le répertoire /etc/ tels que passwd (utilisateurs), group (groupes), host (résolution noms d hôtes/adresse IP), shadow (mots de passe cryptés), etc. Son but est de distribuer les informations contenues dans ces fichiers afin de gérer de façon cohérente, centralisée et automatisée la configuration des postes de travail au sein d un domaine NIS. LDAP Aujourd hui, le format d annuaire LDAP est largement utilisé dans les entreprises notamment de par sa compatibilité multi-plateformes avec des applications web et bureautiques. Il a pris le dessus sur NIS et constitue désormais la meilleure technologie de gestion des utilisateurs et d authentification centralisées. OpenLDAP est la solution d annuaire LDAP de référence car elle offre un bon compromis entre robustesse (montée en charge de la base de données) et facilité d intégration (richesse documentaire) et d administration (possibilité de scripts et interface graphique). Base de données Une base de données peut par définition être utilisée pour stocker les utilisateurs et les groupes associés de l entreprise. Cependant il faut garder à l esprit que la l architecture même de la base de données n est pas optimisée pour répondre à ce type de besoins. En effet dans le cadre d une infrastructure de cette ampleur, les coûts en termes de ressources seront plus importants pour une base de données que pour un annuaire car ce dernier est optimisé pour la lecture. Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 9

10 Tableau comparatif LDAP / Base de Données Critère LDAP Base de données Rapport Lecture/Ecriture Optimisé en lecture Lecture/Ecriture Extensibilité Facile (Schéma LDAP) Difficile (via schéma entitéassociation) Distribution des tables Inhérentes Rare Réplication Possible Possible Modèle transactionnel Simple Avancé Standard Oui Non (spécifique à un SGBD) Tableau comparatif LDAP / NIS (Network Information Services) Critères LDAP NIS Port 389/636 par défaut Arbitraire Chiffrement des données Possible Impossible Mécanismes de contrôle Oui Non d accès Distribution des tables Oui Non Réplication Oui (partielle possible) Oui (uniquement totale) Sémantique des recherches Avancée simple 2. Solution retenue Nous avons présenté deux solutions qui couvrent aussi bien l une que l autre l ensemble des exigences d Aristote en termes d organisation et de gestion des utilisateurs. Toutefois, même si NIS est réputé performant, il présente des lacunes côté sécurité, contrairement à OpenLDAP qui, couplé à Kerberos, permet d authentifier le client et le serveur et de crypter les échanges. Concrètement, cela signifie que, à la différence de NIS, la solution OpenLDAP + Kerberos permet de ne pas diffuser les mots de passe sur le réseau et de garantir que c est le bon serveur qui répond aux requêtes clientes et que ce sont les bons clients qui reçoivent les informations. Etant donné que les deux solutions présentent la même architecture avec des besoins similaires en termes de ressources matérielles, l aspect sécurité constitue, de notre point de vue, un argument déterminant pour une entreprise de l envergure d Aristote. De plus, bon nombre d applications et de matériels réseaux s appuient aujourd hui sur un annuaire LDAP pour la gestion des utilisateurs et même parfois sur kerberos pour offrir l authentification unique (SSO). Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 10

11 3. Implémentation de LDAP dans l architecture d Aristote 1. DIT LDAP Figure 2 - DIT LDAP Une base LDAP est une base de données où les informations sont enregistrées de manière hiérarchique sous forme d arbre et non sous forme tabulaire. Cette arbre LDAP permet d avoir une vue globale de l architecture organisationnelle de l annuaire d entreprise. Ainsi l arbre sera organisé en trois grandes OU, à savoir «People» (regroupera tous les utilisateurs d Aristote), «machines» (listera toutes les stations et serveurs), et enfin «group». Ce dernier servira d attribue permettant de spécifier la direction d appartenance de chaque utilisateur. Cela aura un rôle primordial dans la gestion des accès aux ressources de l entreprise. De plus les OU «People» et «group» seront divisés en quatre sous OU représentatives des sites d Aristote. Enfin, chaque sites de l OU «machines» sera encore subdivisé afin de séparer les machines serveurs des stations utilisateurs. L ensemble des attribues utilisés dans le cadre de l implémentation de cet arbre sont décrit en annexe 1.5 et 1.6 Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 11

12 2. Besoins et ressources Le nombre de machines offrant le service LDAP est directement lié au nombre d utilisateurs accédant à la ressource. Mais d autres facteurs doivent également être pris en compte. On notera par exemple la nécessité d avoir une tolérance aux pannes, des besoins en haute disponibilité (notamment lors des pics I/O le matin à 9h, le midi, et le soir à 18h). Pour toutes ces raisons nous préconisons l installation d un serveur LDAP par site. Ainsi aucun d entre eux ne sera tributaire de la liaison MPLS en cas de dysfonctionnement de cette dernière. Un système de réplication inter-site sera donc mit en place afin de garder une synchronisation permanente et en temps réel des quatre sites (CF : chapitre -> Réplication). De plus, sur le siège d Orsay nous devrons faire face à de très nombreuses requêtes dû au grands nombre d utilisateur. Pour cette raison, il est préférable de mettre en place un cluster LDAP. Ce dernier fonctionnera d une manière bien spécifique afin d optimisé au maximum les flux et les délais de réponse notamment lors des pics I/O. Pour cela nous préconisons la mise en place d un LoadBalancer en amont des deux serveurs LDAP (s appuyant sur l utilisation d une Virtual IP). Ces derniers seront synchronisés en temps réel via un lien dédié leur permettant également de vérifier en permanence l état de leur voisin. Cette partie sera plus largement développée dans le chapitre «Partage de charge (LoadBalancer)». Figure 3 - Besoins Aristote Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 12

13 3. Configuration des serveurs 1. Configuration de LDAP Après installation des paquets slapd et ldap-utils sont demandé les paramètres de bases du serveur : nom de domaine DNS Password de l'admin LDAP Format de la base Autoriser le protocole v2 Vsn-aristote.lan Password LDBM non La configuration du serveur se fera au travers de plusieurs fichiers. Le répertoire ldap se décompose de la façon suivante : LDAP1:~# ls -l /etc/ldap/ total 28 -rw-r--r-- 1 root root 245 jui 24 10:47 ldap.conf drwxr-xr-x 2 root root 4096 jui 24 10:48 sasl2 drwxr-xr-x 2 root root 4096 jan 3 18:44 schema -rw-r root openldap 5399 jan 5 23:50 slapd.conf LDAP1:~# On notera la présence d un répertoire «schema» permettant de décrire les attributs de la base LDAP, ainsi que du fichier slapd.conf. Ce fichier contient l ensemble des paramètres indispensables au fonctionnement de l annuaire dont voici un extrait : suffix "dc=vsn-aristote,dc=lan" rootdn "cn=admin,dc=vsn-aristote,dc=lan" rootpw password loglevel 256 A noté que chaque modification du fichier de configuration /etc/ldap/slapd.conf il est nécessaire de redémarrer le service slapd : # /etc/init.d/slapd restart Enfin, la base de données en elle-même sera située par défaut dans le répertoire suivant : LDAP1:~# ls -l /var/lib/ldap/ total 932 -rw-r--r-- 1 openldap openldap 2048 jan 9 03:16 alock -rw openldap openldap 8192 jan 9 03:16 db.001 -rw openldap openldap jan 9 03:16 db.002 -rw openldap openldap jan 9 03:16 db.003 -rw-r--r-- 1 openldap openldap 96 jan 3 18:47 DB_CONFIG [ ] Pour plus de commodités, nous allons démarrer le serveur LDAP au démarrage de la machine. Pour cela on rajoute au fichier /etc/rc.conf : # LDAP slapd_enable="yes" slapd_flags="-h ldap:///" Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 13

14 Réplication La réplication consiste à mettre en œuvre un serveur primaire, des serveurs secondaires qui seront l'exacte réplique du serveur primaire. Plusieurs méthodes de réplication existent (tel que slurpd), mais nous ne nous attarderons que sur syncrepl qui est la directive la plus flexible et la plus simple à mettre en œuvre. Syncrepl spécifie la base de données comme étant un réplicat dont le contenu est maintenu à jour avec celui du maître en déclarant que le processus courant serveur est un site client de réplication fonctionnant grâce au moteur de réplication dénommé syncrepl. Le contenu du réplicat est maintenu synchronisé avec celui du maître en utilisant le protocole de synchronisation de contenu. Le serveur maître peut envoyer ses mises à jour à intervalles régulières ou dès qu une modification est effectuée. La configuration des serveurs maitre et esclave est détaillé en annexe De plus, il est possible de vérifier en temps réel le bon déroulement des réplications grâce à l application syweno. Cette dernière, s appuie sur le libraire LDAP et deux APIs Java pour remonter les informations de synchronisation, et ainsi garder une parfaite maitrise du bon déroulement des réplications. Partage de charge (LoadBalancer) Le site d Orsay doit être en mesure de répondre à un nombre de requête beaucoup plus important du fait de son nombre d utilisateurs. Pour cela il nous parait primordial de mettre en place un système de partage de charge permettant à deux serveurs de répondre à tour de rôle. Ainsi nous préconisons l implémentation d un LoadBalencer. Une autre solution peut être envisagée, il s agit d utiliser une VIP (Virtual IP). Plusieurs méthodes permettent de définir lequel des deux serveurs doit répondre. Ceci n étant pas le sujet de cette MIR, nous ne développerons pas plus cet aspect. Notons que dans les deux cas la réplication entre ces deux serveur sera géré de manière bidirectionnelle grâce à syncrepl. Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 14

15 Kerberos Les mots de passe des usagers doivent impérativement être acheminés en clair depuis les postes de travail qui hébergent des services jusqu'aux serveurs LDAP chargés des opérations de contrôles. L'utilisation du protocole sécurisé LDAPS (LDAP sur TLS) permet de contourner ce problème puisqu'il impose une session TLS avant tout dialogue LDAP. L'utilisation de services de fichiers mutualisés contrôlés par LDAP accentue ce problème car les mots de passe doivent circuler en clair jusqu'aux services avant d'être acheminés ensuite (éventuellement en LDAPS) jusqu'aux serveurs LDAP. Kerberos fonctionne en environnement hétérogène, assurant la sécurité des échanges sur un réseau non sûr et permettant la mise en place d'un véritable service d'authentification unique. Kerberos utilise un système de chiffrement symétrique pour assurer un dialogue sécurisé entre deux protagonistes. Les dialogues s'opèrent en utilisant une clef secrète et partagée. Les algorithmes de chiffrement sont publics (AES, DES, 3DES,...), toute la sécurité du système repose sur la confidentialité de la clef de chiffrement. Pour faciliter la gestion d'un tel système, Kerberos repose sur l'utilisation d'un tiers de confiance qui distribue les clefs aux utilisateurs et services abonnés. Un serveur Kerberos est appelé KDC (Key Distribution Center). Le service d'authentification assure l'identification unique du client et lui procure un ticket de session qu'il pourra utiliser pour demander des tickets d'utilisation des services kerbérisés. Un ticket de session chiffré avec la clef d'un service kerbérisé constitue un ticket de service. La configuration du serveur KDC ainsi que des clients Kerberos est détaillé en annexe Administration de l annuaire LDAP L administration d un annuaire LDAP, c est-à-dire la création/suppression d utilisateurs, la gestion du parc informatique, etc peut se faire en ligne de commande ou de manière graphique. Cela suppose l ajout d une application tierce qui peut être situé sur le serveur ou sur le client. Plusieurs solutions sont disponibles sur le marché. Notre choix se porte sur l application web ldap-account-manager (présentation et comparaison de différentes solutions en annexe 1.1) On notera la possibilité de réaliser des scripts afin de faciliter cette tâche souvent fastidieuse. Un exemple de script (annexe 1.7) vous permettra d ajouter de nouveaux utilisateur à partir d un fichier prérempli et respectant un formatage défini. Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 15

16 5. Configuration des clients Configuration LDAP L identification des clients auprès de l annuaire LDAP suppose une configuration préalable de ces derniers. Nous allons pour cela nous appuyer sur les deux modules linux PAM et NSS : PAM : Pluggable Authentication Modules (en français : modules d'authentification enfichables) est un mécanisme d'authentification flexible, permettant par le biais de modules, de définir des stratégies et de proposer différents médias comme sources pour l'identification des utilisateurs (bases de données, annuaire, clé USB, ). L'administrateur système n'est plus ainsi limité aux fichiers /etc/passwd et /etc/shadow. L'authentification via PAM ne concerne pas seulement l'accès au système mais tout service que la machine héberge. NSS : Name Service Switch (en français : commutateur de services de nommages), permet de fournir à Linux/Unix non pas des services d'authentification, mais des services de correspondances entre noms, de toutes sortes (noms de machines, utilisateurs, groupes, ), et les identifiants de ces mêmes objets pour la machine (respectivement adresses IP, uid, gid dans l'exemple précédent). NSS, fonctionne de manière similaire à PAM, c'est-à-dire sur la base de modules. Nous devons donc configuré PAM afin de permettre l indentification depuis le serveur LDAP. Cela se fera au travers de quatre fichiers décrit en annexe 1.8. Configuration pour monter les répertoires personnels La gestion des répertoires personnels et leur emplacement est défini dans l annuaire LDAP. Nous allons nous appuyer sur le serveur de fichier NFS pour monter automatiquement les répertoires des utilisateurs. Ainsi nous choisissons que toutes les données personnelles des utilisateurs soient directement enregistrées sur le serveur de fichier NFS et ce de manière transparentes pour les utilisateurs. L implémentation de cette stratégie de gestion des /home nécessite des modifications de configuration au préalable : - du serveur NFS - modification du schéma LDAP - modification de l arbre LDAP L ensemble de ces modifications est plus largement décrit en annexe 1.9 Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 16

17 4. Conclusion Figure 4 - Réplication et cluster LDAP Ce schéma résume bien l idée que le cœur de l infrastructure LDAP se situera au niveau du cluster LoadBalancer d Orsay. La réplication y sera bidirectionnelle et en temps réel. Enfin tous les sites viendront répliquer l ensemble des bases annuaires d Orsay, et notons que les conditions de réplication pourrons être ajustées en fonction de leur impact réseau. Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 17

18 3. Le serveur de configuration IP (Vincent Desseaux) 1. Rappel des besoins Dans le cadre de notre étude, il nous est demandé de mettre en place une solution permettant aux stations Linux du site d obtenir via un serveur DHCP, leur configuration IP. Conformément aux besoins énoncés par Aristote, il convient de rappeler les différents points que nous devons prendre en comptes pour cette partie d étude, afin bien évidement d être cohérents et au plus près de ses attentes. Il nous est donc demandé : - D attribuer via un serveur DHCP les adresses IP des stations Linux du site - De définir un plan d adressage pour les permanents ainsi que pour le personnel itinérant. - De mettre en place une mise à jour automatique de(s) serveur(s) ayant attrait aux noms IP et à leur résolution. De plus, il nous est demandé d intégrer une procédure de mise à jour de l'os et des applications principales du serveur. 2. Introductions Le protocole IP suppose la pré-configuration de chaque ordinateur connecté au réseau avec les paramètres TCP/IP adéquats, ce qu on appelle plus communément l adressage statique. Sur des réseaux de grandes dimensions ou étendues, où des modifications interviennent souvent, l adressage statique engendre une lourde charge de maintenance et de nombreux risques d erreurs, notamment des conflits d adressage. DHCP (Dynamic Host Configuration Protocol) est un protocole réseau dont le rôle est d assurer la configuration automatique des paramètres IP d une station, notamment en lui affectant automatiquement une adresse IP et un masque de sous-réseau, il est l extension même du protocole BOOTP. Mais DHCP ne s arrête pas là, il peut aussi configurer bon nombre d option tel que l adresse de la passerelle par défaut, ou bien encore des serveurs de noms DNS. Les spécifications de ce protocole sont définies par les RFC 2131 (Dynamic Host Configuration Protocol) et RFC 2132 (DHCP Options and BOOTP Vendor Extensions). Dès lors qu on met en place une infrastructure réseau de moyenne ou grande taille tel qu un réseau local d entreprise, il est indispensable de s appuyer sur DHCP pour attribuer les configurations IP des stations. Elle permet une plus grande souplesse lors de la modification d un paramètre commun à toute les stations tel que l adresse IP de la passerelle ou bien encore l adresse IP d un serveur de nom DNS. Dans un environnement Linux, cette fonction est réalisée dans une très majeure partie au moyen du daemon dhcpd. Développé par l ISC (Internet Systems Consortium), il est la version la plus largement utilisé et est fiable et robuste. Nous ne reviendrons donc pas sur le choix de ce produit. Le serveur de configuration IP (Vincent Desseaux) 18

19 3. Présentation du plan d adressage employé Notre plan d adressage IP a pour base les adresses privées de classe B ( /16 à /16). Afin que la solution reste évolutive, on se verra attribuer une adresse réseau de classe B en utilisant le 2ème octet pour différencier chaque site. Seul la DMZ se verra attribuer d un espace d adressage privé de classe A, à savoir le réseau /8. Ci joins en annexe un récapitulatif des réseaux de chaque site à mettre en place. Afin de dissocier au mieux le flux de chaque service et d organiser l espace d adressage, il est décidé de créer des sous réseaux pour chaque site en fonction des directions. Nous utiliserons intégralement le 3 ème octet pour cet usage, ainsi le masque de sous réseau sera de pour chaque direction de chaque site. Sachant également que les sous réseaux mis en place pour un site sont sur le même réseau physique, il convient de mettre en place une politique de VLAN, celui-ci permettra notamment au relai DHCP, dont nous verrons son utilité, de dissocier les flux DHCP des sous réseaux qu il dessert. Ci-joint en annexe l ensemble des sous réseaux que nous allons déployer et l affectation des N de Vlan pour chaque site. 4. Présentation du service DHCP DHCP fonctionne sur le modèle client-serveur : un serveur, qui détient la politique d'attribution des configurations IP, envoie une configuration donnée pour une durée donnée, à un client donné. Lorsqu'un client DHCP initialise un accès à un réseau TCP/IP, le processus d'obtention du bail IP se déroule en 4 requêtes, à savoir les requêtes DHCP Discover, DHCP Offer, DHCP Request et DHCP ACK. Pour qu un client récupère d un serveur DHCP une adresse IP, il doit utiliser le daemon dhclient, le client DHCP de l ISC qui est installé par défaut dans la majeure partie des cas sur les systèmes Linux. Ci-joint en annexe de plus amples sur le Déroulement d attribution d une adresse par DHCP ainsi que la configuration du serveur DHCP Le serveur de configuration IP (Vincent Desseaux) 19

20 5. Autres fonctionnalités lié à DHCP 1. Le relai DHCP Nous avons précédemment vu que les clients contactent les serveurs DHCP à l'aide d'une diffusion. Or dans une architecture inter-réseau, nous devrions théoriquement installer un serveur DHCP par sous-réseau, ce qui induit la multiplication d un même service et par la même, du risque d erreurs liés aux configurations à mettre en place. La RFC 3046 (DHCP Relay Agent Information Option) pallie à ce problème en intégrant une spécification concernant la redirection des paquets DHCP vers un serveur se situant sur un réseau logique distant. Cette fonction est de nos jours, et dans la majeure partie des cas, pris en charge par les routeurs, mais une machine serveur peut être cependant configurée comme agent relai DHCP. Dans les deux types de cas, il suffira de lui spécifier l'adresse du/des serveurs DHCP pour lequel les demandes des clients DHCP seront relayées. Sous Linux, le daemon prenant en charge cette fonctionnalité est «dhcp3-relay». Pour notre client Aristote, nous utiliserons la fonctionnalité relai DHCP des routeurs qui de nos jours, intègrent dans la majorité des cas la fonction de relai DHCP. Nous utiliserons cette fonctionnalité sur chaque site afin de relayer les requêtes clientes qui n appartiennent pas au même Vlan que celui affecté au(x) serveur(s). Malgré la non utilisation d une solution Linux pour cette fonctionnalité, une procédure de mise en place d un relai DHCP sous ce système est proposé en annexe. 2. La haute disponibilité et la répartition de charge Depuis la version 3, le service dhcpd de l ISC supporte l'algorithme de partage de charge conformément à la RFC 3074 (DHC Load Balancing Algorithm). Cet algorithme permet : à plusieurs serveurs DHCP de répartir les adresses IP en fonction d'une stratégie de distribution de mettre en place une stratégie de haute disponibilité Par défaut, la technique pour assurer un partage de charge équitable repose sur un algorithme permettant aux serveurs DHCP d'allouer une adresse en fonction de la parité de l'adresse MAC du client. En effet, le premier serveur allouera une adresse IP si le résultat du hashing de l'adresse est pair, l'autre le fera si le résultat est impair. Les deux serveurs communiquent entre eux par le biais d un canal nommé «failover channel». Ces échanges servent principalement à : informer des octrois de bail s assurer du bon fonctionnement de chaque serveur se répartir les plages d adresses pouvant être alloués Si un serveur DHCP est en panne, le serveur qui reste opérationnel est averti de la défection de son pair et stoppe l'algorithme de partage de charge, il répondra donc à toutes les requêtes clientes. Une fois le serveur DHCP de nouveau disponible, le canal de communication entre les deux serveurs est rétablit, chacun active son algorithme de répartition et le partage de charge des adresses reprend son court. Le serveur de configuration IP (Vincent Desseaux) 20

21 1. Mise en place de la haute disponibilité et de la répartition de charge Le déploiement de cette fonctionnalité s effectue au niveau des fichiers dhcpd.conf en déclarant l affectation du serveur maître et esclave, avec leurs adresses IP ainsi que leurs ports d écoute pour le canal failover (port N 647 par défaut). Ci-joint en annexe la configuration du canal failover du site d Orsay : 3. La mise à jour dynamique des entrées DNS Cette fonctionnalité permet aux ordinateurs clients DNS d'enregistrer et de mettre à jour dynamiquement leurs enregistrements de ressource sur un serveur DNS chaque fois qu'un changement se produit. Ainsi dès qu une machine obtient une adresse IP via DHCP, un nom d hôte lui est automatiquement attribué en fonction de son nom de machine. Les mises à jour dynamiques du DNS peuvent servir en de nombreuses occasions. Par exemple lors d un premier adressage sur le réseau, ou bien encore lors d un changement d adresse IP après une demande de renouvellement de bail ayant échoué, et encore même si l hôte change de sous réseau (s il passe d un réseau filaire à un réseau wifi). Les détails de mise en place de cette fonctionnalité sont détaillés en annexe. Le serveur de configuration IP (Vincent Desseaux) 21

22 6. Intégration du service dans le système d information La distribution qui est imposée aux serveurs sera basée sur un noyau de type Debian, il aurait été possible d intégrer un seul serveur. Mais en prenant en compte des facteurs essentiels tel que la disponibilité et en prenant en compte l impact de la perte de ce service, nous proposons de mettre en place au moins un serveur DHCP par site. Seul le site d Orsay aura deux serveurs DHCP parce qu il contient une quantité d utilisateur relativement importante et que par conséquent, il est le point névralgique de notre infrastructure. Il sera donc question de mettre en place un canal failover pour chaque site. Sachant qu un serveur DHCP peut être composé de plusieurs canaux failover, nous proposons également de mettre en place une solution qui, pour un serveur DHCP donné, intégrera des inclusions de configurations DHCP qui correspondra à chaque site. Typiquement, le fichier dhcpd.conf comportera tout les paramètres concernant son serveur, ensuite nous inclurons les configurations DHCP spécifiques à chaque site dans celui-ci. Le tableau ci-dessous présente la configuration des canaux failover pour chaque site : Site Nom du canal failover Serveur composant le canal Nom du fichier d inclusion Orsay dhcp-failover-orsay ORS-SRV-DHCP1 dhcpd.master.orsay ORS-SRV-DHCP2 Bayonne dhcp-failover-bayonne BAY-SRV-DHCP dhcpd.master.bayonne ORS-SRV-DHCP1 Sophia dhcp-failover-sophia SOP-SRV-DHCP dhcpd.master.sophia Antipolis ORS-SRV-DHCP2 Bruxelles dhcp-failover-bruxelles BRU-SRV-DHCP ORS-SRV-DHCP1 dhcpd.master.bruxelles Dans une configuration de haute disponibilité, il faut que la paire de serveur DHCP qui compose le canal failover ait les mêmes configurations au niveau des déclarations qu ils ont en commun. Si ce n est pas le cas, le canal failover ne sera pas actif. Afin de pallier à ce problème, nous pouvons mettre en place un script qui automatisera le déploiement du fichier de configuration propre à un site sur l hôte distant qui compose la paire. if /etc/init.d/dhcp3-server restart #si le redémarrage du daemon où l on a effectué les modifications c est bien déroulé, alors on peu déployer le fichier sur l autre serveur then scp /etc/dhcp3/dhcpd.master.orsay root@ :/etc/dhcp3/ #on copie via la commande scp vers le serveur distant ssh root@ '/etc/init.d/dhcp3-server restart' #on redémarre le serveur distant else #si le redémarrage du daemon où l on a effectué les modifications a échoué, alors on affiche une erreur echo "Erreur!!! Le fichier de configuration comporte des erreurs. Veuillez regarder le fichier dhcpd.log" fi Le serveur de configuration IP (Vincent Desseaux) 22

23 En ce qui concerne les options de configuration, il convient de mettre en place les informations de base et nécessaire à tout bon fonctionnement dans une architecture informatique d entreprise. Le tableau ci-dessous récapitule tout les paramètres que l on a besoin pour le bon fonctionnement de chaque site, à savoir les paramètres du routeur et des serveurs DNS employés. Site Passerelle (X pour chaque sous-réseau) DNS (par ordre de préférence) Orsay X ; ; ; ; ; Orsay : Réseau X.254 Itinérant Bayonne X ; ; ; ; ; Sophia X ; ; ; Antipolis ; ; Bruxelles X ; ; ; ; ; Plage d adressage dynamique X.50 à X X.50 à X X.50 à X X.50 à X X.50 à X Définition des paramètres communs à mettre en place pour Aristote Ces paramètres seront mis en place dans les fichiers dhcpd.conf de tous les serveurs. Paramètre Valeur Commentaire option domain-name "vsn-aristote.lan" Définit le suffixe DNS à utiliser ping-check 1 Permet d éviter des conflits d adressage default-lease-time Définition du temps d un bail par défaut à 1 journée max-lease-time Définition du temps d un bail par défaut à 5 journées authoritative Serveur faisant autorité sur le segment log-facility local7 indique un fichier de log de niveau debug ddns-domainname "vsn-aristote.lan" zone de nom sur lequel DHCP effectuera les mises à jour ddns-update-style interim Choix de l algorithme de mise à jour du DNS ddns-updates on Mise à jour autorisée ignore client-updates MAJ par le dhcp et non par le client update-static-leases on on MAJ des statiques DHCP allow-unknow-clients Autoriser les clients inconnus au niveau de l'adresse MAC 2. Relais DHCP Comme mentionné dans l étude des fonctionnalités avancée de DHPC, il est bon de rappeler que le relai DHCP est intégré sur les routeurs de chaque site. Chaque relai fera suivre les requêtes DHCP aux serveurs composant la grappe failover d un site. Le serveur de configuration IP (Vincent Desseaux) 23

24 3. Schéma de l architecture DHCP à mettre en place Figure 5 - Architecture DHCP 7. Les pré-requis et coûts de la solution 1. Les pré-requis DHCPd ne requiert seulement comme pré-requis : - Un noyau linux intégrant le module prenant en charge le protocole 802.1q pour les relais DHCP - Disposer des droits d'administration sur le serveur - Connaître les bases fondamentales de TCP/IP (adressage, sous-réseaux, etc.) 2. Coûts de déploiement La mise en place de la solution, l application d une batterie de tests ainsi que sa validation représente un coût humain de 10 heures/homme par serveur DHCP, 4 heures/homme par serveur relai DHCP soit un total de 66 heures/homme que nous allons arrondir à 68, soit 8,5 jours ouvrés. Les serveurs, au nombre de 5, peuvent parfaitement être virtualisé par site, ce que nous conseillons bien évidement pour des raisons de coûts matériel. 3. Coûts lié à l administration L intégration des postes clients Linux représentera un coût d administration, tout comme la gestion des serveurs DHCP où les fichiers de configurations peuvent être modifiés. Nous estimons cette charge de travail à 1 jour ouvré par semaine. Le serveur de configuration IP (Vincent Desseaux) 24

25 4. Résolution de noms IP (Rudy Promé) 1. Rappel des besoins Avant de démarrer l étude, il est nécessaire de rappeler les besoins de notre client Aristote afin que les propositions des outils et logiciels à mettre en œuvre soient cohérentes. Dans cette partie, il s agit donc de prévoir une organisation centralisée de la résolution des noms de machines du site. Il faudra être en mesure d assurer une haute disponibilité à ce rôle car, sans lui, la communication entre les machines clientes et serveurs de l infrastructure serait impossible. 2. Solution que nous proposons Dans le monde Unix, on distingue plusieurs solutions libres et gratuites pour tout type de services réseaux. Dans notre étude, nous nous intéressons plus particulièrement à ces solutions gratuites afin de réduire les coûts de la mise en place de l infrastructure de notre client. 1. Bind9 Concernant le service de résolution de noms IP, nous retiendrons Bind9 permettant une multitude de fonctions qui une fois bien configurée, allège considérablement le travail de l administrateur dans le temps : Il est capable de fonctionner de façon autonome et dynamique, ce qui permettra d ajouter automatiquement les clients utilisant ce serveur dans la base DNS, au lieu d ajouter les 800 clients (1000 à venir) d Aristote manuellement Afin d assurer une continuité d activité, les serveurs Bind9 peuvent communiquer entre eux pour mettre à jour leur base DNS dynamiquement et fonctionner par principe de «Maître- Esclave». En cas de crash du serveur Maître, les serveurs Esclaves sont alors présents pour prendre le relais, il n y a donc ainsi aucune interruption d activité et tout est entièrement transparent pour les utilisateurs Suite à notre expérience lors de la précédente étude (concernant l infrastructure de messagerie), nous avons utilisé le service DNS Bind9 qui était largement à la hauteur de nos espérances en matière de montée en charge. Les différents serveurs que nous allons implémenter pourront gérer sans peine les requêtes de tous les utilisateurs d Aristote 2. Le nom de domaine Comme indiqué dans le cahier des charges, la nom de domaine de notre client devra correspondre à «vsn-aristote». Pour se faire, nous utiliserons deux suffixes :.lan : pour tout le réseau interne d Aristote.eu : pour sa visibilité depuis l extérieur L utilisation de ces deux suffixes nous permettra de dissocier très simplement ce qui sera donc accessible depuis l extérieur et l intérieur. Résolution de noms IP (Rudy Promé) 25

26 3. Implémentation de Bind9 (Serveur Maître) 1. Installation Son installation est relativement simple en recourant aux binaires (à l aide de la commande apt-get install). Mais on peut également procéder à une installation par compilation qui pourra correspondre plus spécifiquement à la machine afin de rendre le serveur plus performant. Mais ceci nécessite des connaissances en Linux un peu plus expérimentées. 2. Configuration Une fois le serveur installé, il faut le configurer en créant son fichier de zone et en lui indiquant qu il est le serveur Maître. Pour voir la procédure plus en détails, référez-vous à l annexe Configuration Bind9 serveur Maître. 3. Les enregistrements dynamiques Il faut ensuite le rendre dynamique pour que les postes clients d Aristote s enregistrent automatiquement dans la base DNS. Il y a deux méthodes pour les enregistrer automatiquement : la première consiste à effectuer l enregistrement lorsque les postes eux-mêmes interrogent le serveur DNS la seconde consiste à effectuer les enregistrements par le serveur DHCP au moment où celuici distribue les adresses IP des postes clients C est la seconde méthode que nous utiliserons car l inconvénient principal de la première méthode est que si un poste A tente de communiquer avec un poste B alors que le B n a pas interroger le serveur DNS (et n est donc pas enregistré), il sera impossible d effectuer un échange quelconque entre les deux postes. Pour paramétrer cette fonction, il est nécessaire d indiquer dans un premier temps au serveur DHCP qu il doit envoyer aux serveurs DNS. Dans le fichier /etc/dhcp3/dhcpd.conf, il faut préciser le nom de domaine utilisé et qui est le serveur DNS de la zone. Lors de la distribution des adresses, après avoir reçu le paquet DHCPREQUEST du poste client et avant de lui transmettre le DHCPACK, il met à jour le serveur DNS en ajoutant un enregistrement A (hôte). Enfin, si le poste client demande une réattribution de son adresse IP avec un message DHCPRELEASE pour annuler le bail de son adresse, le serveur DHCP supprime de la base DNS les enregistrements concernés. Dans un second temps, il faut informer le serveur Bind9 qu il doit autoriser le serveur DHCP à effectuer des mises à jour dans sa base DNS. Pour ceci, il faut ajouter la variable «allow-update { ; } ;» 1 dans le fichier /etc/bind/named.conf dans l arborescence créée pour le domaine «vsn-aristote.lan». Après redémarrage des services DHCP et DNS, la mise à jour dynamique est fonctionnelle. 1 Commande pour autoriser les mises à jours de la base DNS depuis qui est le serveur DHCP 1 d Orsay Résolution de noms IP (Rudy Promé) 26

27 4. Implémentation des serveurs Esclaves 1. Haute disponibilité pour le siège Le site d Orsay étant le siège de notre client, il est nécessaire d assurer de la haute disponibilité pour le service de résolution de noms IP. C est pourquoi sur ce site, nous allons mettre en place un deuxième serveur Bind9, mais celui-ci sera configuré en Esclave. Pour voir la procédure de configuration en détails, référez-vous à l annexe Configuration Bind9 serveur Esclave. 2. Les sites distants Les trois serveurs distants sont un peu particuliers. Ils seront serveurs Esclaves tout comme le serveur secondaire situé à Orsay. Mais ils assureront les requêtes de leur site respectif. Pour ceci, le serveur DHCP de chaque site distant devra se référer au bon serveur DNS. Ainsi, les postes clients de chaque site utiliseront leur serveur DNS attitré pour résoudre les requêtes. Ces serveurs seront donc Esclaves d Orsay mais «Maîtres» de leur site. Nous ne reviendrons pas en détails sur leur configuration car elle est exactement la même que celle du serveur Esclave d Orsay. Pour rappel, il faudra donc leur renseigner leur rôle d Esclave, leur serveur Maître, la zone vsn-aristote.lan et la fonction de notifications. Du côté du Maître, on ajoute les trois serveurs dans les enregistrements de vsn-aristote.lan.hosts et d ajouter leur adresse IP à l option d autorisation de transfert de zone. 3. Les postes clients Les configurations DNS des clients délivrées par le serveur DHCP sera différente selon le site où ils situent. Voici un tableau récapitulatif : Clients des sites Orsay Bayonne Sophia Antipolis Bruxelles DNS Primaire DNS Secondaire Sur le site d Orsay, en cas de non réponse du serveur Maître, les clients seront donc aptes à interroger le serveur secondaire d Orsay. Sur les sites distants, en cas d impossibilité de résoudre les requêtes qui leurs sont attribuées, elles seront automatiquement renvoyées vers le serveur Maître via le réseau MPLS. Résolution de noms IP (Rudy Promé) 27

28 5. Supervision des serveurs A l aide d un serveur de supervision tel que Nagios (que nous implémentons également dans l infrastructure de notre client), nous pouvons surveiller en temps réel l état de nos serveurs DNS. En cas de détection d anomalies de l un de nos serveurs, nous pouvons être automatique averti par mails afin de procéder au plus vite à la résolution de celles-ci. La supervision via Nagios est plus détaillée dans la suite de notre étude, dans la partie qui lui est concernée. De plus, nous pouvons consulter l historique des évènements des serveurs en se référant à leur fichier de journalisation, situé dans /var/log/syslog. Je recommande d utiliser les commandes suivantes afin de filtrer les informations qui nous intéressent dans le fichier de journalisation : - more /var/log/syslog grep bind -> afin d afficher toutes les informations sur Bind9 - tail -50 /var/log/syslog -> afin d afficher les 50 dernières lignes du fichier «syslog» Vous pouvez également vous référez à l annexe «Phases de tests DNS» pour une liste de commandes permettant de tester le bon fonctionnement des serveurs Bind9. 6. Schéma physique de l architecture DNS Comme cité précédemment, Aristote comptera donc 5 serveurs DNS : 1 serveur Maître situé sur le site d Orsay qui se chargera de résoudre toutes les requêtes à Orsay 4 serveurs Esclaves, soit un sur chaque site. Le serveur Esclave d Orsay qui aura pour tâche de prendre le relais du serveur Maître en cas d incident ou de surcharge de travail et les 3 serveurs Esclaves des sites distants qui résoudront les requêtes de leur site correspondant Figure 6 : Schéma infrastructure DNS Résolution de noms IP (Rudy Promé) 28

29 7. Coûts Etant donné qu il s agit d une solution entièrement gratuite sur le plan logiciel, il s agira alors uniquement de coûts matériels et humains. 1. Coûts matériels Il est fortement recommandé de mettre le serveur Maître d Orsay sur une machine physique car c est le serveur qui traitera le plus de requêtes DNS. Il est donc impératif que ses cartes réseaux ne soient pas également utilisées par un autre serveur afin de pouvoir assurer les charges réseaux les plus élevées possibles. Quant à tous les autres serveurs, les serveurs dits Esclaves, ils seront installés sur des plateformes de virtualisation avec d autres serveurs afin de minimiser les coûts matériels.. Nous aurons donc besoin d un serveur HP ProLiant DL120 à 1350 hors taxes. 2. Coûts humains Le site d Orsay disposant du serveur DNS Maître devra-être administré par au minimum deux administrateurs Linux. Les trois sites distants quant à eux pourront être assuré par un seul administrateur Linux par site. Orsay Bayonne Sophia Antipolis Bruxelles Nombre d utilisateurs (avant l évolution de 20 %) Nombre de serveurs DNS Nombre d administrateurs Total Le coût d un administrateur est évalué à 2000 brut mensuel. Le total des coûts humains s élève donc à brut mensuel. Donc par an. 3. Conclusion L infrastructure DNS en environnement Linux de notre client Aristote reviendra donc à un coût total d environ hors taxes par an. Pour rappel, le coût inclut la mise en place de l infrastructure ainsi que son administration. 8. Maquette A contrario de ce que nous avons cité dans l étude de l architecture DNS, pour des raisons matérielles, les serveurs DNS seront installés sur les mêmes machines que les serveurs DHCP lors de la phase de maquettage et de la rédaction de notre cahier de recette. De plus, étant donné que nous ne maquettons pas le site d Orsay, nous ne pourrons vous présenter le Cluster DNS d Orsay. Il sera donc présenté d une façon similaire mais entre les deux sites distants, à savoir Bayonne et Bruxelles. Bayonne aura pour rôle serveur Maître et Bruxelles, serveur Esclave. Résolution de noms IP (Rudy Promé) 29

30 5. Le serveur de ressources (Jérôme Delahaie) 1. Rappel du besoin : Mettre à disposition de chaque service un espace partagé. Cet espace doit permettre aux utilisateurs de ces services d accéder à trois espaces : Informations modifiables que par les rédacteurs Travail collaboratif Logiciels partagés Deux fonctionnalités peuvent-être implémentées : Interopérabilité avec le système Windows, sans utiliser le logiciel Samba Une gestion dynamique du service afin d optimiser la bande passante 2. Solutions existantes : Pour répondre à ce besoin, plusieurs solutions peuvent être envisagées. 1. L appliance matérielle : Cette solution peut nous être fournie par beaucoup de sociétés, les meilleures sur le marché sont NetApp (leader mondial) et EMC². Le principal avantage de cette solution est qu elle comprend un support complet (matériel/logiciel) et garanti par contrat. Elle permet de réaliser tous les besoins du client. 2. L appliance logicielle : Cette solution permet d avoir un système clé en main et facilement administrable. Les solutions présentes sur le marché sont OpenFilter, FreeNAS et CryptoNAS. OpenFilter permet de profiter d un support garanti par contrat mais qui se limite à la partie logiciel et sans prendre en charge la partie matérielle. FreeNAS et CryptoNAS sont des distributions orientées NAS. La première est basée sur FreeBSD et la deuxième sur Debian. Ces distributions permettent de profiter d une interface spécialisée afin de gérer le NAS, aussi bien la gestion des filesystems que des droits. Le principal point noir concernant ces distributions réside dans le fait qu elles utilisent toutes le logiciel Samba. On peut donc se poser des questions sur la pérennité de telles solutions. De plus, la mutualisation des serveurs est difficile avec ces distributions, l ajout de services étant périlleux. 3. Serveur Linux ou Unix Cette solution est en fait l ajout du service «serveur NFS» sur un serveur Linux ou Unix. Tout comme la solution précédente, cette solution nécessite l achat d un serveur, l installation du système, la mise en place du service et son intégration dans l environnement. Cette solution permet de pouvoir répondre au cahier des charges avec un partage de type NFS et de se libérer de la contrainte Samba. Le système permet de pouvoir mutualiser d autres services. Le serveur de ressources (Jérôme Delahaie) 30

31 4. Solution retenue Nous allons retenir la troisième solution, c est la solution qui nous donne le plus de flexibilité par rapport aux différents besoins de notre client. Toutefois, si le besoin en volumétrie est supérieur à 20Tio, nous vous recommandons l utilisation d une appliance matérielle. 3. Architecture proposée 1. Besoins par sites Aristote dispose de quatre sites distants, où quasiment toutes les directions sont représentées. Le tableau suivant récapitule les données dont nous disposons sur les machines présentes. Orsay effectif %age/site %age global Bayonne effectif %age/site %age global générale 40 10,00% 66,67% 4 2,22% 6,67% administrative 30 7,50% 66,67% 10 5,56% 22,22% commerciale 70 17,50% 60,87% 16 8,89% 13,91% études ,75% 78,46% 20 11,11% 6,15% production 5 1,25% 1,89% ,67% 45,28% total Sophia-Antipolis Bruxelles générale 1 1,25% 1,67% 15 9,38% 25,00% administrative 0 0,00% 0,00% 5 3,13% 11,11% commerciale 4 5,00% 3,48% 25 15,63% 21,74% études 10 12,50% 3,08% 40 25,00% 12,31% production 65 81,25% 24,53% 75 46,88% 28,30% total On constate que la moitié des utilisateurs se trouve sur le site d Orsay. C est donc le lieu sur lequel le besoin doit être le plus grand. Nous ne disposons d aucune donnée sur la volumétrie existante, le profil I/O ou les systèmes de fichier à supporter. Afin de palier à ce manque d information, cette étude se basera sur un profil I/O standard : 1 000% de charge à 9h et 18h à la (dé)connexion de tout le monde 30% en journée et 0% la nuit. 2. Analyse de l usage Avant toute chose, il faut savoir que les performances d un serveur de fichier sont principalement impactées par : Le réseau Les I/O que peuvent fournir les disques Le serveur de ressources (Jérôme Delahaie) 31

32 Charge serveur Sur ce serveur de fichier, nous ciblons principalement deux usages : Espace partagé par direction (besoin du client) Stockage des répertoires personnels des utilisateurs Le premier usage est un usage régulier sur toute la journée, les utilisateurs consultant et utilisant les documents de manière aléatoire. Le deuxième usage est un peu plus complexe. Il y a en effet deux grosses périodes de très forte charge, qui sont : le matin à la connexion des utilisateurs le soir lorsqu ils partent. Il faut donc prévoir ces montées en charge dans le design de notre solution. Trafic réseau et optimisation La manipulation de fichiers sur le serveur génère un trafic réseau important en nombre de paquets. La MTU d un réseau Ethernet étant de 1500 octets, le transfert d un fichier de 1Mo sur le serveur va générer un trafic de l ordre de 700 paquets. Lors de la partie MIR Réseau, nous avions une contrainte qui était d avoir un réseau Ethernet gigabit. Le réseau Ethernet gigabits ne peut pas être exploité pleinement avec un MTU de 1500 octets. L utilisation de jumbo frames autorise un MTU de 9000 octets, et permet d exploiter pleinement un réseau Ethernet gigabit. En reprenant le même exemple, notre fichier de 1Mo ne générera plus qu un trafic de l ordre de 120 paquets. Le bémol de cette solution réside dans l obligation d avoir l intégralité de l équipement réseau en Ethernet gigabit. Charge disque Un disque SCSI standard fournit une performance de l ordre de 120 IOPS. Pour simplifier le dimensionnement du serveur, on calcule le nombre d IOPS en prenant pour base un IOPS par utilisateur. Sur Orsay, qui est le site où l on compte le plus d utilisateurs, on a actuellement 400 utilisateurs, il faut donc au minimum un RAID composé de 5 disques. En prévoyant l augmentation de 20% sur 5 ans, il nous faut au minimum 6 disques. Si on opte pour du RAID 5, il faut compter un disque de plus pour la parité. Si on veut une tolérance de panne de 2 disques, on peut ajouter un disque spare, qui sera utilisé automatiquement en cas de défaillance d un disque. Le serveur de ressources (Jérôme Delahaie) 32

33 3. Solutions face aux contraintes : Solution pour la contrainte réseau L utilisation des jumbos frames est une solution qui est envisageable car le réseau est en Ethernet gigabit. Nous ne la retenons pas car l utilisation du serveur ne le justifie pas, mais c est une évolution qui pourrait être mise en place si le besoin s en fait sentir. L autre solution pour améliorer la partie réseau est l adoption d un cluster NFS. Ce mode pourrait permettre de répartir la charge lors des pics d utilisation, et ainsi doubler la bande passante. Et lors du fonctionnement normal, un seul serveur serait sollicité. Cette solution permet donc de fournir le service même lors de montée en charge et d offrir une gestion dynamique de la bande passante. Le cluster sera assuré par le logiciel Heartbeat et la répartition de charge par le load balancer utilisé par le cluster LDAP. Solution pour la contrainte disque La solution consiste à utiliser plusieurs disques, afin de combiner leurs capacités pour atteindre le seuil d I/O nécessaire. Le serveur va pour ce faire bénéficier de disques utilisés en RAID par un contrôleur matériel. D un point de vue logiciel, les disques seront gérés par la couche LVM. Cette solution permet de pouvoir ajouter très simplement de la volumétrie. LVM organise les disques (PV : physical Volume) en Volume Group (VG). Ce VG s utilise avec des LV (Logical Volume). Figure 7 - Schéma de synthèse LVM Ces LV sont redimensionnables et il n y a pas les limitations dû aux types de partition. Ici le VG ne contiendra que le volume RAID. LVM permet également de faire des snapshots, une fonction intéressante pour la sauvegarde. Le serveur de ressources (Jérôme Delahaie) 33

34 Les différents partages seront regroupés par direction au sein d un lv. Cette solution permet de pouvoir étendre à chaud la volumétrie allouée à une direction. Nous proposons d utiliser le système de fichier GFS2, car il prend en charge correctement la problématique de l accès concurrent. Gestion des droits et client Les droits d accès seront gérés par le biais du service NSS et de son module LDAP. Le client nfs sera le paquet Debian standard, et afin d avoir plus de transparence pour l utilisateur, les répertoires seront montés par le biais de l outils autofs dès le login et démontés après la déconnexion. (cf annexes Répertoires utilisateurs) Solution pour l interopérabilité avec Windows La version 4 du service NFS permet l interopérabilité des droits POSIX avec les droits Windows. Cela va permettre de simplifier la traduction des droits en l un ou l autre des systèmes. Aristote nous fait part de ses réserves quant à la pérennité du logiciel Samba, nous devons donc nous tourner vers d autres solutions. La solution que nous avons retenue est l installation de Microsoft Subsystem for Unix-based Applications (SUA). Cette solution, dont les premières versions datent de 1999, permet à Windows d être client NFS. Actuellement, SUA supporte NFS version 4. Répartition des serveurs Nous proposons de mettre en place un serveur de fichier par site à l exception du le site d Orsay où nous proposons un cluster de serveur de fichier. Toutes les données seront répliquées sur Orsay afin de permettre aux personnes de continuer à travailler si l un des serveurs vient à tomber en panne. Le cluster sur le site d Orsay permet de grandement réduire les risques de dysfonctionnement du service. 4. Coûts Nous proposons la configuration présentée en annexe pour tous les sites. Sur Orsay, cette configuration sera doublée, pour chacun des nœuds du cluster. Avec cette configuration, le volume maximal de donnée utile pouvant être stocké est 3,6Tio. Item quantité prix unitaire prix total M , ,00 MD , ,00 Total ,00 Tableau récapitulatif des coûts Le serveur de ressources (Jérôme Delahaie) 34

35 6. Système de sauvegarde (Arnaud Hamon) 1. Rappel des besoins L objectif de cette partie consiste à prévoir une sauvegarde des répertoires /home des utilisateurs des 3 sites. Chaque service doit disposer sur le serveur de sauvegarde d un espace par service et par machine. LA sauvegarde doit être automatisée pour chaque soir à partir de 1h du matin. - Option 1 : Gestion de l taille et dulieu de stockage sur une année d exercice. - Option 2 : Gestion de l archivage et du temps de restauration sur une année d exercice. 2. Comparatif L objectif est de déterminer la solution qui répond le mieux aux besoins du client. Le choix de cette solution est basé sur des solutions reconnus par leur utilisation. Les solutions proposées : - Rsync - Backup-manager - Backuppc Un tableau comparatif a été mis en place pour recouper les besoins client avec les fonctionnalités des solutions. Tableau comparatif Besoins du client Rdiff-backup Backup-manager Backuppc Sauvegardes de OUI OUI OUI répertoires Sauvegardes multisites OUI OUI OUI Sauvegardes NON OUI OUI automatisées Différents types de NON OUI OUI sauvegardes Restauration OUI OUI OUI Multiples OS NON NON OUI Système de sauvegarde (Arnaud Hamon) 35

36 3. Solution retenue Dans l étude du système de sauvegarde, Backuppc est la solution qui a été conseillée. Cette solution est la plus complète et ouvre des possibilités sur la mise en place de sauvegardes des configurations de chaque serveur, de données autres que les /home des utilisateurs. 1. Architecture de fonctionnement Voici le schéma de fonctionnement de la solution. Cluster de serveurs de fichiers - LoadBalancer ORS-SRV-FILES /24 ORS-SRV-FILES /24 VIP /24 HA ,2/24 Cluster Files Serveur de backup ORS-SRV-BACKUP /24 Backup NAS Netgear LAN server LAN users VPN-MPLS Internet Figure 8 - Implémentation serveur de backup Rappelons que l objectif est de sauvegarder des répertoires /home des utilisateurs. Système de sauvegarde (Arnaud Hamon) 36

37 Tout d abord, le serveur de sauvegarde n a aucun impact sur le bon fonctionnement de la production du client, c est pourquoi un cluster de serveur de sauvegarde ne sera pas utile dans cette optique de sauvegarde de données en cas de pertes de celles-ci. En cas de perte du serveur de sauvegarde, il n y aura aucun impact sur la production du client Aristote. Un seul serveur sera mis en place afin de gérer les sauvegardes qui sera situé sur le site de Orsay. Caractéristique technique du serveur mis en place CPU Mémoire Physique Mémoire Virtuelle Espace disque (SWAP) Core 2 Duo 2Ghz 4Go 2Go 50Go Ceci est la configuration recommandée pour le fonctionnement du serveur de sauvegarde. Ensuite, afin d assurer la remise en fonctionnement en cas de crash du serveur, un ghost sera réalisé afin de rétablir la machine. Seulement, il faut penser aux différentes mises à jour des configurations de sauvegarde, d où l importance de mettre en place une sauvegarde de celle-ci. Finissons avec l élément important de cette infrastructure, le NAS. Le choix de stockage sur un NAS est stratégique. Premièrement, une amélioration à la tolérance de panne grâce à 4 disques utilisés en RAID5 et donc un intégrité des données en cas de perte d un des disques. Deuxièmement, les performances d un NAS en RAID5 sont bien adaptées aux besoins en termes de vitesse d écriture/lecture par la répartition de charges. (Voir le chapitre Espace de stockage pour les informations concernant l espace disque du NAS). Grâce à l outil de supervision qui sera mis en place (Voir partie 8 option 1), une supervision de services de sauvegarde et de l état des disques du NAS pourra être mis en place. 2. Backkuppc Backuppc est un logiciel permettant de sauvegarder un parc de serveurs ou de postes client. Il est muni d une interface web afin de faciliter son utilisation et de paramétrer les différents sauvegardes et faire des restaurations en cas de besoin. Il permet principalement de mettre en place des sauvegardes automatisées de répertoires de serveurs ou poste client de manière régulière. Backuppc peut utiliser différents protocole: - Samba - rsync - rsyncd - Tar Les répertoires étant centralisés sur un serveur Linux, on utilisera rsync afin de les sauvegarder. Système de sauvegarde (Arnaud Hamon) 37

38 3. Gestion de la taille du lieu de sauvegarde Type de sauvegarde La taille des sauvegardes varie en fonction du type de sauvegarde réalisé. Backuppc utilise 2 types de sauvegardes : - Les sauvegardes complètes : Elle permet de sauvegarder l intégralité des données. C est la sauvegarde la plus simple et la plus rapide à restaurer. Seulement, elle est très gourmande en ressource (réseaux), et demande énormément d espace de stockage. - Les sauvegardes incrémentielles : Elle permet de sauvegarder uniquement les données modifiées depuis la dernière sauvegarde incrémentielle ou complète. Moins gourmande en ressources et espace disque, il est par contre moins facile de réaliser une restauration d un sauvegarde incrémentielle car il faut pour cela, restaurer la dernière sauvegarde complète et toute les incrémentielle depuis celle que l on veut restaurer. Pour répondre aux besoins de sauvegarde journalière, nous allons utiliser les 2 types de sauvegardes afin de réaliser toutes les sauvegardes en réduisant au maximum l utilisation d espace disque. De plus, Backuppc gère très bien la restauration des sauvegardes incrémentielles et cela est totalement transparent. Espace de stockage Afin de répondre aux besoins de sauvegarde des /home de différents utilisateurs, il va falloir étudier la quantité d espace nécessaire afin de pouvoir stocker l ensemble des données et prévoir une augmentation du nombre d utilisateur de 20% en 5 ans. Nous allouerons 500 Mo par utilisateur. Nous prendrons comme référence 820 collaborateurs. Sachant que pour la plupart des utilisateurs, ils n utiliserons pas la totalité des 500 Mo et qu ils ne modifieront pas la totalité des 500Mo de fichiers sur leur répertoire, on allouera 1Go par personne de sauvegarde. Nombre d utilisateurs Espace alloué Espace alloué pour la sauvegarde Go 820Go %=984 On arrondit à Go 1000Go On aura donc besoin de mettre en place un serveur NAS de 1 To afin de réaliser les sauvegardes. On utilisera le modèle suivant : Netgear ReadyNas3100 8TB Network Storage System. Il peut lui mettre jusqu à 8 TB d espace disques. Pour des questions technologique, on mettra en place 4TB d espace de disques. Cela permettra de mettre en place d autres sauvegardes mais aussi que l utilisation du RAID5 réduit de manière assez significative l espace disque utilisable. Backuppc ne sauvegarde qu à un seul endroit /var/lib/backuppc. C est pourquoi le NAS sera monté sur la Debian et un lien symbolique sera mis en place pour rediriger les sauvegardes directement sur le NAS. Système de sauvegarde (Arnaud Hamon) 38

39 Méthode de sauvegarde Comme vu précédemment, Backuppc utilise 2 méthodes de sauvegarde. L objectif va être ainsi d optimiser l efficacité des sauvegardes tout en réduisant au maximum l espace utilisé pour les sauvegardes. Samedi Dimanche Lundi Mardi Mercredi Jeudi Vendredi Sauvegarde Complète Sauvegarde Incrémentielle Sauvegarde Incrémentielle Sauvegarde Incrémentielle Sauvegarde Incrémentielle Sauvegarde Incrémentielle Sauvegarde Incrémentielle Figure 9 - fonctionnement des sauvegardes Rappelons que dans le cahier des charges, il est précisé que la sauvegarde doit être automatisée pour chaque soir à partir de 1H du matin. Nous allons ainsi voir les variables à implémenter dans Backuppc afin d y répondre. Tout d abord, nous allons réaliser une sauvegarde complète hebdomadaire durant le weekend. Techniquement, cette sauvegarde peut être réalisé à n importe quel moment de la semaine, or les ressources en bande passante sont limités et la volumétrie à sauvegarde peut varier de quelques giga-octets de données à à des centaines de giga-octets de données ce que pourrait provoquer des saturations sur le réseau et ainsi des latences sur le réseau. Durant le weekend, il y aura beaucoup moins de personnes qui risquent d être perturbés par les sauvegardes et vers 1H du matin. $Conf{FullPeriod} = 6.97; Variable configurée afin de réaliser un backup toute les semaines Ensuite, il faut trouver un compromis entre le temps d archivage des données et l espace nécessaire pour stocker les informations. C est pourquoi nous recommandons de conserver les sauvegardes que sur une durée hebdomadaire. Ainsi, l espace disque nécessaire sera réduit et la sauvegarde sur une semaine semble correcte face aux besoins des sauvegardes. jours. $Conf{FullAgeMax} = 9; // Age maxi d une sauvegarde complète, supprimé au-delà de 9 $Conf{FullKeepCntMin} = 1; // Garder au minimum une sauvegarde complète, même si elle a plus de 9 jours. En cas de problème et de non sauvegarde du serveur, il n y aurait plus de sauvegardes car elles auraient toutes passées le cap des 9 jours, donc le serveur n aurait plus du tout de sauvegarde. Ce qui aurait un impact critique. Maintenant, nous allons mettre en avant l efficacité des sauvegardes à partir des sauvegardes incrémentielles. Pour cela, une sauvegarde incrémentielle journalière sera mise en place. Cependant, il faut aussi prendre en compte l archivage des sauvegardes incrémentielles. Vu que l archivage se fera sur une semaine, il faut prendre en compte le nombre de sauvegardes incrémentielles entre chaque sauvegarde complète, qui est de 6 sauvegardes incrémentielles. Pour Système de sauvegarde (Arnaud Hamon) 39

40 garder une marge de manœuvre pour les sauvegardes manuelles, on gardera en archivage les 8 dernières sauvegardes incrémentielles. $Conf{IncrKeepCnt} = 8; // Garder au minimum 8 sauvegardes incrémentielles $Conf{IncrKeepCntMin} = 3; // Garder au minimum 8 sauvegardes incrémentielles quelques soit la date d archivage pour les mêmes raisons que le paramètre $Conf{FullKeepCntMin}..Pour finir, on va programmer le serveur afin qu il démarre ses actions de sauvegardes à partir de 1H, grâce au paramètre $Conf{WakeupSchedule}. Ce paramètre permet de renseigner à quel moment le serveur doit faire ses vérifications pour savoir si il a une action à réaliser ou non. $Conf{WakeupSchedule} = [1]; 4. Gestion du temps de restauration des fichiers Il est vrai que sauvegarder ses données être très important. Seulement sans restauration les sauvegardes sont inutiles. Backuppc proposer 2 méthodes de restauration : - la restauration directe: à partir de l interface WEB, on peut directement sélectionner les données à restaurer et le serveur se charger de les pousser la machine sur lequel il faut restaurer les données. - La restauration manuelle : à partir de l interface WEB, il est possible de télécharger les données que l on veut restaurer. 4. Coûts Software/Hardware Coût Backuppc Gratuit Serveur 1000 Netgear ReadyNas3100 8TB 4500 Network Storage System En ce qui concerne l intégration, nous estimons à 5 jours/homme la mise solution. Pour l ensemble des tâches, nous estimons le coût d administration à 1heure /homme par semaine. Système de sauvegarde (Arnaud Hamon) 40

41 7. Le serveur web et l'accès internet sécurisé (Bastien Gayral) 1. Rappel des besoins 1. Objectif L objectif est la mise en place d un serveur Web et d'un accès Internet sécurisé dans l entreprise. Le serveur Web doit offrir : un accès public. un accès privé réservé au personnel. L accès doit autoriser : la navigation et la consultation sur le Web, les connexions sur le site web de l entreprise depuis un poste itinérant. 2. Exigences et option Définir une politique d accès sécurisé sur Internet. Etudier et mettre en place les fonctions associées à la politique définie. Option1: Un outil de statistiques réseaux est consultable en intranet. Il s'agit d'analyser en autre la charge de bande passante à l'aide de simulations et de mesures. Option2: L'authentification est homogénéisée à celle d'unix ou est centralisée par un annuaire. Option3: Un proxy-cache annexe est envisagé. Option4: Un firewall autorisant uniquement les ports ftp(gestion du mode passif), ssh, http, https est envisagé Le serveur web et l'accès internet sécurisé (Bastien Gayral) 41

42 2. Serveur Web 1. Présentation Un serveur Web, est un logiciel servant des requêtes respectant le protocole de communication clientserveur Hypertext Transfer Protocol (HTTP), qui a été développé pour le World Wide Web. Un ordinateur sur lequel fonctionne un serveur HTTP est appelé serveur Web. Le terme «serveur Web» peut aussi désigner le serveur HTTP (le logiciel) lui-même. Les deux termes sont utilisés pour le logiciel car le protocole HTTP a été développé pour le Web et les pages Web sont en pratique toujours servies avec ce protocole. D'autres ressources du Web comme les fichiers à télécharger ou les flux sont en revanche fréquemment servies avec d'autres protocoles. Source : Wikipédia 2. Les logiciels de serveur HTTP Lighttpd Lighttpd est un serveur Web léger sécurité et rapide. Son avantage est qu il consomme peu de ressource. Mais il ne supporte les fichiers.htaccess et htpasswd, fichiers permettant de définir des règles dans un répertoire. Nginx Nginx est un serveur HTTP léger, performant et sécurisé. Depuis sa création sa popularité n'a cessé de croître. Ce serveur Web est réputé pour ses performances et sa faible consommation mémoire. Il est facile à mettre en œuvre et contient de nombreuses fonctionnalités. Nous ne conseillons pas ce produit car il manque de maturité et sa documentation n existe qu en anglais et en russe. Apache Le serveur HTTP Apache est très largement diffusé dans les distributions Linux. C est ce qui explique sa popularité dans le monde car c est le serveur web le plus fréquemment utilisé avec environ 60% des sites Web (source Netcraft voir figure 1). Il est intéressant de le choisir pour ses multiples fonctionnalités grâce à des modules. C est également un projet qui possède une communauté extrêmement nombreuse. Apache dispose de nombreuses fonctionnalités, il permet l'utilisation de modules, la possibilité de définir une configuration spécifique pour chaque répertoire partagé, des restrictions. Il est souvent utilisé avec des modules comme Perl et/ou PHP afin de rendre le contenu des pages dynamiques. Figure 10 : Source Netcraft 2010 Le serveur web et l'accès internet sécurisé (Bastien Gayral) 42

43 L Apache http serveur est une application complète et gratuite. Apache a mis en œuvre différents modules gérant chaque fonctionnalité afin de facilité la gestion et l administration. De plus, il existe une grande quantité de documentations et de mise à jour sur Internet. Nos administrateurs ont choisi le serveur Web d Apache car c est un produit mature et stable. 3. Architecture du serveur web Figure 11: Implémentation du serveur web Nous vous proposons de mettre en œuvre deux serveurs web, un dans la DMZ qui sera configuré pour le site public et un dans le réseau LAN pour le site intranet. En effet, pour sécuriser l accès et mieux répartir la charge nous avons choisi de séparer les deux accès. 4. Accès public Il s agit de votre site internet qui sera visible par tous les internautes aucune authentification ne sera nécessaire. 5. Accès privé (Intranet) Ce site sera uniquement accessible aux personnels de l entreprise qui devront être authentifié par l annuaire LDAP. Cet accès privé sera disponible sur le réseau interne ou depuis un poste itinérant possédant un accès VPN que nous expliquerons dans le prochain chapitre. Cet accès permettra à vos utilisateurs d accéder à diverses ressources comme par exemple leur répertoire utilisateur afin de pouvoir télécharger leurs documents ou des pages HTML donnant des informations privées ou des formulaires (note de frais). Le serveur web et l'accès internet sécurisé (Bastien Gayral) 43

44 3. Accès internet sécurisé 1. Introduction Internet est un outil indispensable dans le milieu professionnel, il est devenu également un moteur de partage de connaissances. Les entreprises sont de plus en plus axées sur l'aspect social, collaboratif et ouvert à tous d Internet ce qui engendre l obtention de données inadéquates, non vérifiées, voire même de contenus malveillants. Par conséquent, les entreprises se trouvent face à la problématique de devoir concilier les exigences d un accès à l information disponible sur Internet tout en assurant la sécurité de leurs données et de leurs réseaux. Nous vous proposons de mettre en place une politique d accès à Internet. C est la stratégie qui protègera votre réseau afin de ne pas être attaqué aussi bien depuis l extérieur que depuis l intérieur. Chaque donnée émise sera analysée et traiter selon les règles en vigueur. Afin de répondre au cahier des charges, notre choix s est porté sur l utilisation d un serveur proxy. Un tel système réduit de façon considérable le risque d attaque, à condition d avoir fournit des règles de sécurité. 2. Présentation Le rôle premier d un serveur proxy est de servir de relais entre deux réseaux. Dans certain cas, les proxys peuvent être "anonymisant" c'est-à-dire qu'il ne reste pas de traces de l'émetteur de la requête lorsque le service distant est contacté. Il peut également être utilisé pour de filtrage les données, c'est-à-dire assurer un suivi des requêtes vers Internet effectuées par les utilisateurs et filtrer les sites de destination par URL ou par contenu (les vidéos par exemple). 3. Fonctionnement Le principe de fonctionnement d'un serveur proxy est très simple : il s'agit d'un serveur "mandaté" par une application pour effectuer une requête sur Internet à sa place. Ainsi, lorsqu'un utilisateur se connecte à internet à l'aide d'une application cliente configurée pour utiliser un serveur proxy, celleci va se connecter en premier lieu au serveur proxy et lui donner sa requête. Le serveur proxy va alors se connecter au serveur que l'application cliente cherche à joindre et lui transmettre la requête. Le serveur va ensuite donner sa réponse au proxy, qui va à son tour la transmettre à l'application cliente. 4. Proxy cache Une autre des fonctions de Squid, est de servir de "cache" (proxy-cache). C'est-à-dire de stocker localement les contenus ou les URL les plus souvent demandés pour les restituer quasi immédiatement. Pour optimiser le gain de temps et de bande passante, nous vous conseillons de mettre un serveur Proxy Squid sur chaque site. Le serveur web et l'accès internet sécurisé (Bastien Gayral) 44

45 5. Implémentation du proxy Comme nous l avons vu dans la partie précédente, nous vous proposons l installation de quatre serveurs proxys. Figure 12 : Implémentation des proxys Squid 6. Installation et configuration Installation L administration des solutions Linux est assez complexe ainsi que leur configuration. Afin, d optimiser les ressources systèmes, et éviter les problèmes de plantage, nous avons choisis d installer les serveurs proxys en mode script. Sur debian, il suffit d utiliser la commande suivante pour l installation de Squid : apt-get install squid. Contrôler les accès Pour contrôler tout ce qui passe par votre serveur proxy, vous pouvez utiliser ce que l'on appelle les ACL (Access Control List). Les ACL sont des règles que le serveur applique. Cela permet par exemple d'autoriser ou d'interdire certaines transactions. On peut autoriser ou interdire en fonction du domaine, du protocole, de l'adresse IP, du numéro de port, d'un mot, on peut aussi limiter sur des plages horaires. Le serveur web et l'accès internet sécurisé (Bastien Gayral) 45

46 Authentification Nous avons choisis de contrôler vos utilisateurs en fonction de l annuaire OpenLDAP. Voici les ajouts à réaliser dans le fichier squid.conf : acl identification proxy_auth REQUIRED http_access allow identification authentificate_program /usr/lib/squid/squid_ldap_auth \ -b $LDAP_USER -u uid ldap.vsnaristote.lan 7. Conclusion Squid est un logiciel proposant des fonctionnalités nombreuses et configurables. Il permettra une meilleure gestion de vos utilisateurs ainsi qu une sécurité supplémentaire de votre réseau. Le serveur web et l'accès internet sécurisé (Bastien Gayral) 46

47 8. Mise en place d un Firewall avec Netfilter/Iptables (Vincent Desseaux) IPtables et Netfilter fournissent les fonctionnalités de filtrage disponibles sous Linux à partir du noyau 2.4. Netfilter effectue le filtrage proprement dit, tandis qu IPtables fournit les commandes nécessaires à la programmation des filtres. IPtables fournit trois types de fonctionnalités : Filtrage : statique (stateless) ou dynamique (stateful) et connection tracking NAT: traduction d adresses IP, source NAT, destination NAT, masquerade, redirection de port (il faut noter que IPtables ne permet pas d effectuer du NAT statique) ; Marquage et manipulation de paquets. Ce firewall se situera à la frontière du réseau LAN d Orsay, des sites annexes, de la DMZ et du réseau Internet. Il sera donc nécessaire de disposer d au minimum 4 interfaces réseau sur la machine enrobant cette fonctionnalité. Ci-joint en annexe un récapitulatif de la commande iptables ainsi que le tableau recensant l ensemble des règles à appliquer sur le firewall. Il convient également de mettre en place le routage par forwarding et que la machine prenne en charge le support du NAT/PAT. La configuration d IPtables se fait initialement en script de commande, c est pourquoi son administration peut être fastidieuse et nécessite de l expérience et des connaissances techniques appropriées. Afin de rendre cette tâche d administration plus conventionnelle, nous proposons d intégrer le composant webmin qui permet d'administrer un serveur UNIX ou Linux à distance via une interface graphique web. Mise en place d un Firewall avec Netfilter/Iptables (Vincent Desseaux) 47

48 9. Serveur VPN (Bastien Gayral) 1. Introduction Il est demandé dans le cahier des charges, un accès au site intranet de votre entreprise accessible par votre personnel itinérant. Ces clients nomades «roadwarrior» utilisent des adresses IP inconnues attribuée dynamiquement pour se connecter à votre réseau. Il est pour cela nécessaire de mettre en place une autorité de certification ainsi qu un serveur VPN. 2. Présentation Un VPN (Virtual Private Network ou Réseau Privé Virtuel en français) permet de relier deux réseaux distants à travers Internet. Il est possible de faire communiquer ces deux réseaux comme s ils étaient connectés directement ensemble. Un cryptage est rajouté entre les deux connectiques qui vont initier la VPN à l aide d un procédé de tunnelisation 3. Solutions VPN existantes Sur les systèmes Linux, plusieurs initiatives ont été créées pour répondre au besoin de VPN. Il existe plusieurs types de VPN fonctionnant sur différentes couches réseau, voici les VPN que nous pouvons mettre en place sur un serveur dédié : - une solution Open Source IPSec comme OpenS/WAN - une solution Open Source qui utilise la technologie SSL comme OpenVPN. - une solution Open Souce qui utilise du SSH encapsulé par le protocole PPP comme OpenSSh Openswan Le projet Openswan qui propose une implémentation des protocoles IPSec et IKE pour les noyaux Linux. Adapté à des configurations fixes, la technologie IPSec s'avère efficace pour des connexions entre sites ou avec des PC distants gérés par l'entreprise. Il convient moins aux nomades car les parefeu risquent de bloquer le trafic. OpenVPN Le projet OpenVPN, il s agit d un VPN reposant sur la couche de sécurisation SSL très facile à déployer. Ses principaux atouts sont de passer au-dessus des pare-feu et d avoir un client (navigateur) présent sur tous les PC. Il fonctionne derrière du NAT et gère les changements d'adresses pour les clients connectés en DHCP. C est solution que nous avons retenu car elle répond pleinement au cahier des charges. OpenSSH Depuis sa version 4.3, le logiciel OpenSSH permet de créer des tunnels entre deux interfaces réseau virtuelles. Toutefois, OpenSSH ne gère que la création de ces tunnels, la gestion (routage, adressage, pontage, etc...), c'est-à-dire la création du VPN utilisant ces tunnels, restant à la charge de l'utilisateur. Serveur VPN (Bastien Gayral) 48

49 4. Implémentation de VPN dans l architecture d Aristote OpenVPN est un système permettant de relier des postes distants sur un réseau informatique en passant par Internet mais de manière sécurisée (Tunnel VPN). Figure 13 : Implémentation du serveur VPN Le schéma ci-dessus représente votre architecture réseau. Le but est donc de créer un tunnel entre vos utilisateurs nomades et le serveur pour que le client situé à l extérieur accède à votre réseau local. Pour communiquer avec un poste du réseau LAN ( ), le client ( ) passera donc par le tunnel jusqu'au serveur OpenVPN ( ) et sera ensuite routé sur votre LAN. Création des certificats et des clés La première étape dans la construction d une configuration OpenVPN est d établir une Infrastructure de Clés Publiques (PKI en anglais). Une ICP fonctionne grâce à : Une clé publique pour le serveur et une clé privée pour chacun des clients Un certificat de l Autorité de Certification maître et des clés qui sont utilisées pour identifier (signer, identifier ) chaque certificat serveur et client. OpenVPN est livré avec plusieurs scripts permettant de générer plus facilement les clés et les certificats pour OpenSSL. Ces scripts sont enregistrés dans le dossier «easy-rsa». Nous allons générer un certificat et une clé privée pour le serveur et les clients nomades à l aide des commandes : /build-key-server VPN-SERVER # clé pour le serveur /build-key-server Nomade1 # clé pour le client dont le Cn est Nomade1 Pour chaque client, le champ Common Name doit être renseigné et unique. Serveur VPN (Bastien Gayral) 49

50 5. Configuration du serveur VPN Premièrement, pour limiter les risques d attaques sur OpenVPN, il est important que le processus d OpenVPN fonctionne sur un utilisateur n ayant aucun droit sur le système. C est pourquoi nous allons créer un nouvel utilisateur. Pour télécharger et installer OpenVPN : #apt-get install openvpn La configuration ci-dessous est stockée dans le fichier "/etc/openvpn/server.conf" : Comme annoncé précédemment, les postes client utiliseront la distribution ubuntu. Il est nécessaire d installer openvpn et le pluging network-manager-openvpn. Ce dernier sert pour le gestionnaire réseau, vous permettant de configurer facilement un client, et ensuite pouvoir le démarrer 6. Conclusion Cette solution est assez simple à mettre en place. Elle est particulièrement intéressante pour les clients nomades. Ils peuvent, quelque soit l'endroit où ils se trouvent, mettre en place un VPN entre le client et un serveur, sans avoir à se soucier de l'état du réseau sur lequel ils se trouvent, et peuvent utiliser quasiment tous les services réseau sans se préoccuper des règles installées sur les pare-feux, puisque tous les services sont routés dans le même tunnel. Serveur VPN (Bastien Gayral) 50

51 10. Outil de monitoring système et réseau (Arnaud Hamon) Rappel : Un outil de statistiques réseaux est consultable en intranet. Il s agit d analyser en autre la charge de bande passante à l aide de simulations et de mesures. Dans le monde open source, on retrouve une multitude de solutions de monitoring systèmes et/ou réseaux tel que : - Cacti : repose principalement sur le protocole SNMP. C est principalement utilisé pour la métrologie réseau. - OpenNMS : Outil de supervision SNMP mais limité dans ses foinctionnalités. - Nagios : Outil de supervision (Ordonnaceur). Afin de répondre aux besoins, une solution Nagios et pnp4nagios est la solution la plus adaptée. Nagios peut superviser les équipements réseaux ainsi que les équipements système tel que AIX, Linux ou bien encore Windows. La grande force de Nagios est une supervision basée sur des plug-ins. Ses plug-ins permettent de superviser la grande majorité des métriques nécessaires et la grande facilité de conception et/ou optimisation de ses plug-ins en fond l outil de supervision open source le plus utilisé. Nagios ne gère pas les données métrologiques, c est pourquoi pnp4nagios sera ajout à nagios afin de produire des graphiques de performances pour certaines métriques comme la charge CPU, les espaces disques. Nagios propose une interface WEB afin de visualiser les métriques remontées. Grâce à la mise en place de seuil sur les métriques remontées, on peut générer des alertes sur l interface afin de prévenir de possibles latences, saturation de disques ou la perte de services comme messagerie ou bien antivirus. De plus, pnp4nagios s appuie sur cette même interface. On met en place des liens sur l interface WEB (aussi appelé console de supervision) afin de rediriger vers les graphes de performances. Voici un exemple de graphe généré à partir de PnP4Nagios : Figure 14 - Graphique NAgios Ce graphe représente les temps de réponse au ping en précisant la valeur minimum, maximum et moyenne sur une journée. Outil de monitoring système et réseau (Arnaud Hamon) 51

52 11. Infrastructure global (Jérôme TENEUR) Infrastructure global (Jérôme TENEUR) 52

53 12. Conclusion (Jérôme TENEUR) Après cette étude, nous avons arrêté nos choix sur les différents éléments nécessaires pour la réalisation de l intranet en environnement Linux. Voici le résumé de nos différents choix dans les solutions Linux : - L organisation et la gestion des utilisateurs : OpenLDAP - Le serveur de configuration IP : DHCP ISC - La résolution des noms IP : BIND 9 - Le serveur de ressources : NFS 4 - Le serveur de sauvegarde : BackupPC - Le serveur web et l accès internet sécurisé : Apache et IpCop + Squid - Firewall : IPtable + NetFilter - Serveur VPN : OpenVPN - Monitoring et gestion des incidents : Nagios L ensemble de ces solutions seront implémentées dans les environnements suivants : - L environnement réel soit les 4 sites qui furent décrit dans le chapeau du projet MIR - L environnement lors de la maquette soit le site d Bayonne et de Bruxelles avec le matériel disponible pour les serveurs et/ou les postes clients Conclusion (Jérôme TENEUR) 53

54 13. Bibliographie Installation du serveur LDAP Kerberos DHCP Options DHCP Relai DHCP MAJ Dynamique DNS Répartition de charge DHCP : Bibliographie 54

55 DNS Serveur de Backup Supervision Nagios Ouvrage «Nagios 3 pour la supervision et la métrologie» de Jean Gabès Partage de ressources : lenny FR/Red_Hat_Enterprise_Linux/5/pdf/Cluster_Suite_Overview/Red_Hat_Enterprise_Linux-5- Cluster_Suite_Overview-fr-FR.pdf reiserfs-xfs-nfs/ Bibliographie 55

56 Serveur Web VPN Bibliographie 56

57 7. Lexique 802.1q : Standard de l IEEE qui fournit un mécanisme d'encapsulation des VLAN s, permettant ainsi du trunk de VLAN s sur une même interface. DHCPREQUEST : message client aux serveurs qui confirme la validité des adresses précédemment allouées ou qui demande les paramètres à un serveur DHCPRELEASE : client qui demande au serveur de libérer son adresse, d annuler le bail DHCPACK : le serveur envoie au client les paramètres de configuration Enregistrement A : enregistrement d hôtes Enregistrement NS : enregistrement des serveurs DNS Enregistrement SOA : enregistrement du serveur d autorité de la zone Samba : Utilise le logiciel SmbClient pour le transfert des données. C'est un bon choix pour sauvegarder des machines sous Windows. rsync : Utilise le logiciel RSync pour le transfert des données (via SSH). C'est un bon choix pour sauvegarder des machines sous Linux et sous windows. rsyncd : Utilise le daemon «rsyncd» installé sur chaque client. C'est un bon choix pour sauvegarder des machines sous Linux et sous Windows. Tar : Utilise le logiciel Tar. C'est un bon choix pour sauvegarder des machines sous Linux. Ssh : Secure Shell est à la fois un programme informatique et un protocole de communication sécurisé. Nas : Network Attached Storage Certificat électronique : Un certificat contient, tel un passeport ou une carte d identité, un ensemble d informations administratives sur son propriétaire (nom, prénom, adresse électronique, etc.), sur sa validité, et sur l organisme d émission. Il contient également la clé publique de l utilisateur et un sceau (la signature électronique de l autorité de certification) nécessaire à la vérification de son authenticité. Il permet de garantir l identité du possesseur de la clé privée associée. Client/Serveur :L'architecture client/serveur désigne un mode de communication entre plusieurs ordinateurs d'un réseau qui distingue un...) Protocole http : Le Hypertext Transfer Protocol, plus connu sous l'abréviation HTTP, littéralement le «protocole de transfert...) Le World Wide Web : littéralement la «toile d'araignée mondiale», est communément appelé le Web. Bibliographie 57

58 RPV (réseau privé virtuel) ou VPN (Virtual Private Network) : Le RPV consiste à utiliser un réseau public (Internet). Les infrastructures, mutualisées, se révèlent meilleur marché, mais la confidentialité n'est plus garantie. D'où la nécessité de crypter les informations. SSL (Secure Socket Layer) : Méthode d'authentification et de cryptage utilisée par les premiers navigateurs Netscape. La version SSL 3.0 a constitué la base lors de la création du protocole TLS (Transport Layer Security), défini par l'ietf (Internet Engineering Task Force), l'organisme de normalisation du monde IP. Tunnel (ou tunneling) : Technique qui consiste à placer les trames d'un protocole dans un autre, de niveau équivalent ou inférieur selon la nomenclature du modèle OSI. Elle est utilisée pour transporter les trames d'un réseau d'entreprise à travers un réseau public. Les routeurs de ce dernier ne voient que les entêtes propres au réseau public. Bibliographie 58

59 14. Annexes 1. Organisation et gestion des comptes utilisateurs (Jérôme Teneur) 1. Choix de l environnement graphique L administration et la consultation au quotidien de l annuaire OpenLDAP peut se faire au travers de plusieurs interphases graphiques. Tous les produits de qualité professionnelle que l on peut retrouver offre des fonctions d ajout/suppression d utilisateurs et de machines, la répartition de ces derniers dans différentes unité organisationnelle, etc Les plus répandus étant : JXplorer phpldapadmin ldap-account-manager JXplorer est un client LDAP phpldapadmin est une LAM est basé sur développé en Java sous une interface écrite en php qui phpldapadmin et viens licence opensource de type permet de modifier facilement rajouter des scripts et OSI. Il permet de lire ou modifier le contenu de tout annuaire LDAP ou annuaire X500. et via une interface conviviale un annuaire LDAP. améliorations. Il s utilise donc au travers d un navigateur web. Le choix de l outil d administration est souvent très personnel car fonction d habitudes et de goût. En effet, dans leurs fonctions de base ces différents produits se valent. Cependant les communautés permettant l évolution de ces produits ne sont pas toutes équivalentes, de plus tous ne sont pas aussi aisément modifiables pour parfaire aux besoins qui de ses utilisateurs. Pour ces raisons nous préconisons l utilisation de LDAP Account Manager. Cependant le choix final incombera toujours à l utilisateur si ce dernier préfèrerait s orienter vers un autre produit. Annexes 59

60 2. Mise à jour de l annuaire Manuelle La mise à jour de l annuaire ldap se fait au travers de fichier LDIF (LDAP Data Interchange Format). Ces fichiers contiennent des entrées de la forme suivante : Création d une nouvelle OU Création d un utilisateur dn: ou=people,dc=example,dc=com ou: People objectclass: top objectclass: organizationalunit # jerome, Bayonne, People, vsn-aristote.lan dn: uid=jerome,ou=bayonne,ou=people,dc=vsnaristote,dc=lan objectclass: shadowaccount objectclass: posixaccount objectclass: inetorgperson objectclass: organizationalperson objectclass: person homedirectory: /home/jerome loginshell: /bin/bash uid: jerome cn: Jerome Teneur uidnumber: sn: Teneur givenname: Jerome gidnumber: Enfin, le fichier LDIF doit être intégré à la base de l annuaire. Cela se fait au travers de la commande : # ldapadd -x -f fichier.ldif -W -D cn=admin,dc=vsn-aristote,dc=lan Graphique La création de nouveaux utilisateurs peut également être entreprise via LDAP Account Manager. Un menu de configuration assisté permet de définir tous les attribues de l utilisateur. Seul regret, il n est passible de créer qu un utilisateur à la fois ce qui peut s avérer lourd en terme de charge administrative. Annexes 60

61 Automatique La création automatique d utilisateur se fera au travers d un script spécialement développé qui : 1- lit le nom du fichier contenant les utilisateurs (un utilisateur par ligne et les attribues séparés par «;») 2- lit le nom du groupe auquel appartiendront les utilisateurs, 3- lit de façon récursive le fichier en entrée et extrait pour chaque ligne le nom et le prénom de l utilisateur, 4- génère un fichier LDIF temporaire contenant les comptes utilisateurs à ajouter dans la base OpenLDAP, 5- arrête le démon OpenLDAP, 6- appelle la commande d ajout d objet dans la base OpenLDAP avec le fichier LDIF temporaire, 7- démarre le démon OpenLDAP, 8- supprime le fichier LDIF temporaire. 3. Tests de l annuaire L annuaire est maintenant disponible sut le port 389 en TCP et de manière chiffrée sur le port 636 en TCP. Pour valider le bon fonctionnement du service, on peut interroger l annuaire avec la commande ldapsearch fournie par le paquet ldap-utils installé précédemment. Par exemple, pour faire une requête LDAP : # ldapsearch -x -H ldap:// b "ou=people,dc=vsnaristote,dc=lan" "(objectclass=*)" Pour utiliser le mode SSL avec ldapsearch, il faut dans un premier temps ajouter la ligne suivante dans le fichier /etc/ldap/ldap.conf pour ignorer la vérification du certificat : TLS_REQCERT allow Il suffit maintenant de reprendre la même requête en modifiant l URI et en ajoutant l option -Z : # ldapsearch -x -H ldaps:// :636 -Z -b "ou=people,dc=vsnaristote,dc=lan" "(objectclass=*)" Annexes 61

62 4. Kerberos 1. Serveur [kdcdefaults] kdc_ports = 750,88 [realms] VSN-ARISTOTE.LAN = { database_name = /var/lib/krb5kdc/principal admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab acl_file = /etc/krb5kdc/kadm5.acl key_stash_file = /etc/krb5kdc/stash kdc_ports = 750,88 max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = des3-hmac-sha1 supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3- hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3 default_principal_flags = +preauth } [logging] kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmin.log default = FILE:/var/log/krb5lib.log Client L utilisation de Kerberos se fera au travers des modules linux krb5-user et libpam-krb5. Une modification de /etc/krb5.conf permettra de spécifier le server KDC : S en suit une modification de PAM afin qu il prenne en compte Kerberos : # /etc/pam.d/common-account - authorization settings common to all services account sufficient pam_unix.so account sufficient pam_krb5.so account required pam_deny.so # /etc/pam.d/common-auth - authentication settings common to all services auth sufficient pam_unix.so nullok_secure auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so # /etc/pam.d/common-password - password-related modules common to all services password sufficient pam_unix.so nullok obscure min=4 max=8 md5 password sufficient pam_krb5.so use_first_pass password required pam_deny.so # /etc/pam.d/common-session - session-related modules common to all services session optional pam_unix.so session optional pam_krb5.so Annexes 62

63 5. Liste partielle des attributs LDAP de la classe «organization» Attribut Description businesscategory Activité professionnelle d une entreprise ou d une personne c Code du pays en deux lettres (respectant le standard ISO 3166) cn Nom de l objet (common name) description Description de l objet distinguishedname Nom distingué (utilisé par d autres attributs par héritage) facsimiletelephonenumber Numéro de fax givenname Prénom de la personne houseidentifier Identifiant d un batiment initials Initiales d une personne internationalsdnnumber Numéro ISDN l localité de l objet (géographique) member Distinguished Name des membres name Nom (utilisé par d autres attributs par héritage) o Nom de l organisation objectclass Classe d objets ou Unité organisationnelle (branche de l organisation) owner Nom du propriétaire de l objet postaladdress Adresse postale (sans le code postal) postalcode Code postal postalofficebox Boîte aux lettres (postale) presentationaddress Adresse réseau de la présentation de l objet (généralement une URL vers la présentation en ligne) protocolinformation Attribut complémentaire à presentationaddress pour définir le protocole à utiliser registeredaddress Adresse postale pour des envois de courriers recommandés et de colis seealso DN d objets complémentaires serialnumber Numéro de série de l objet sn Nom de famille de la personne (surname) st Etat ou région (state) streetaddress Nom de la rue et assimiilé (boulevard,...) telephonenumber Numéro de téléphone title Titre de la personne (différent de fonction) uid Identifiant unique de l objet userpassword Mot de passe de l utilisateur Annexes 63

64 6. Liste partielle des attributs LDAP de la classe «inetorgperson» cn Nom Sémantique Mono Obl Lecture Utilisation nom(s) O RI Ordre : Nom, Prénom. Attention : pas complet(s) d accent pour simplifier les recherches. (d usage) Voir aussi displayname. Exemple : sans accent "Bugale Jerome" displayname nom complet avec accents employeetype type de personnel facsimiletelephonenumber Numéro de fax Version accentuée de la valeur principale de cn. Exemple : "Bugalé Jérôme" D? RI? Définir les grandes familles? RI Format E 123 (cf Références) givenname Prénom M D RI idem sn. Exemple : "Jérôme" labeleduri Page RI personnelle mail adresse mel M RI? canonique mobile numéro de RI Format E 123 (cf Références) téléphone mobile o Nom de l organisation ou Unité organisationnelle (branche de l organisation) postaladdress Adresse postale RI Adresse complète. Attention au format ("$" séparateur, voir RFC2256) postalcode Code postal preferredlanguage langue M RI cf RFC2068 préférée sn Nom O RI Contient le nom d usage. Il est possible d ajouter le nom de famille (nom patronymique) en seconde valeur. Tout caractère diacritique. Première lettre en majuscule. Voir aussi cn. Exemple : "Bugalé". st Etat ou région (state) telephonenumber numéro de RI Format E 123 (cf Références) téléphone fixe title titre RI Responsabilité ; président, directeur,... (cf Harpège?). Code ou intitulé complet? uid identifiant unique M D R utilisé comme rdn, contenu indifférent mais aussi court que possible usercertificate certificat X509 A? Annexes 64

65 7. Script création utilisateurs #! /bin/sh #On affiche un avertissement à destination de l'administrateur : echo " " echo " VOUS ETES SUR POINT D'AJOUTER DES UTILISATEURS A LA BASE LDAP! " echo " " echo "" #On demande à l'administrateur de saisir le chemin complet du fichier contenant les utilisateur et on récupère ce chemin dans la variable "fichier" : echo "Veuillez saisir le chemin complet du fichier contenant les utilisateurs : " read fichier echo "" #On affiche la liste de groupes et on demande à l'administrateur d'indiquer le numero du groupe pour lui éviter la saisie : echo "Liste des groupes :" echo " " echo "[1] Direction Generale" echo "[2] Direction Administrative et Financiere" echo "[3] Direction Commerciale et Marketing" echo "[4] Direction des Etudes" echo "[5] Direction Production" echo "" echo "Veuillez saisir le numero correspondant au groupe auquel appartiendront les utilisateurs :" #On récupère le numero saisi par l'administrateur dans la variable "numgroupe" : read numgroupe echo "" #On retranscrit le numero saisi par l'administrateur en nom d'unité organisationnelle et gid de groupe au sens annuaire LDAP et on les affecte respectivement aux variables "nomgroupe" et "idgroupe" : case $numgroupe in 1) nomgroupe="direction generale" idgroupe="1001" ;; 2) nomgroupe="direction administrative et financiere" idgroupe="1002" ;; 3) nomgroupe="direction commerciale et marketing" idgroupe="1003" ;; 4) nomgroupe="direction des etudes" idgroupe="1004" ;; 5) nomgroupe="direction production" idgroupe="1005" ;; Annexes 65

66 esac #On détruit le fichier "/tmp/slapaddtemp.ldif" qui aurait pu ne pas etre effacé lors d'un précédent appel du script : rm /tmp/slapaddtemp.ldif #On lit ligne par ligne le fichier "fichier" jusqu'au bout et on affecte respectivement aux variables "nompersonne" "prenompersonne" chaque champ délimité par le caractère ":" #On utilise ces variables ainsi que "idgroupe" et "nomgroupe" pour construire un fichier LDIF temporaire "/tmp/slapaddtemp.ldif" #On génère aléatoirement un uid pour chaque utilisateur avec la commande RANDOM : while IFS=: read nompersonne prenompersonne do ID=$RANDOM echo "dn: uid=$prenompersonne $nompersonne,ou=$nomgroupe,dc=aristote,dc=mir" >> /tmp/slapaddtemp.ldif echo "uid: $prenompersonne $nompersonne" >> /tmp/slapaddtemp.ldif echo "cn: $prenompersonne $nompersonne" >> /tmp/slapaddtemp.ldif echo "objectclass: account" >> /tmp/slapaddtemp.ldif echo "objectclass: posixaccount" >> /tmp/slapaddtemp.ldif echo "objectclass: top" >> /tmp/slapaddtemp.ldif echo "objectclass: shadowaccount" >> /tmp/slapaddtemp.ldif echo "userpassword: password" >> /tmp/slapaddtemp.ldif echo "shadowlastchange: 14909" >> /tmp/slapaddtemp.ldif echo "shadowmax: 99999" >> /tmp/slapaddtemp.ldif echo "shadowwarning: 7" >> /tmp/slapaddtemp.ldif echo "loginshell: /bin/bash" >> /tmp/slapaddtemp.ldif echo "uidnumber: $ID" >> /tmp/slapaddtemp.ldif echo "gidnumber: $idgroupe" >> /tmp/slapaddtemp.ldif echo -e "homedirectory: /home/$prenompersonne $nompersonne\n" >> /tmp/slapaddtemp.ldif done < $fichier #On arrête le démon du serveur OpenLDAP : /etc/init.d/slapd stop #On ajoute les objets utilisateurs à partir du fichier LDIF temporaire avec la commande slapadd : slapadd -l /tmp/slapaddtemp.ldif #On démarre le démon du serveur OpenLDAP : /etc/init.d/slapd start #On supprime le fichier LDIF temporaire : rm /tmp/slapaddtemp.ldif Annexes 66

67 8. Configuration des clients LDAP /etc/pam.d/common-account account required pam_unix.so account sufficient pam_ldap.so /etc/pam.d/common-auth /etc/pam.d/common-passwor /etc/pam.d/common-session auth required pam_env.so auth sufficient pam_unix.so likeauth nullok auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so password required pam_cracklib.so retry=3 minlen=2 dcredit=0 ucredit=0 password sufficient pam_unix.so nullok use_authtok md5 shadow password sufficient pam_ldap.so use_authtok password required pam_deny.so session required pam_limits.so session required pam_unix.so session optional pam_ldap.so Et enfin, on modifie le fichier de configuration de NSS : /etc/nsswitch.conf passwd: ldap compat group: ldap compat shadow: ldap compat 9. Configuration pour le montage des répertoires personnels Modification du serveur NFS Créer le répertoire de l'utilisateur et donner les autorisations pour modifier ses données sur le serveur (o+rwx) user@serveur:~$ sudo mkdir /home/serveur sudo mkdir /home/serveur/dupont sudo chmod go+rwx /home/serveur/dupont Modification du schéma LDAP Il est nécessaire d ajouter dans le fichier nis.schema le schema "automount.schema" pour automount Le schéma définit un attribut automountinformation et deux classes d'objet. De plus une instance de classe automount contient au moins deux attributs : cn et automountinformation. Annexes 67

68 ~ fichier automount.schema ~ attributetype ( NAME 'automountinformation' DESC 'Information used by the autofs automounter' EQUALITY caseexactia5match SYNTAX SINGLE-VALUE ) objectclass ( NAME 'automount' SUP top STRUCTURAL DESC 'An entry in an automounter map' MUST ( cn $ automountinformation ) MAY ( description ) ) objectclass ( NAME 'automountmap' SUP top STRUCTURAL DESC 'An group of related automount objects' MUST ( ou ) ) Modification de l arbre LDAP Nous pouvons indiquer l'emplacement du homedir sur le serveur avec les options de montage Automount recherche un objet LDAP automount dont l'attribut cn correspond au login. Enfin nous pouvons modifier l arbre LDAP manuellement via un fichier LDIF : ~ fichier au.ldif ~ dn: cn=dupont,ou=people,dc=vsn-aristote,dc=lan objectclass: top objectclass: automount cn: dupont automountinformation: fstype=nfs,hard,intr,nodev,nosuid,rw :/home/serveur/dupont Annexes 68

69 2. Récapitulatif des réseaux de chaque site à mettre en place (Vincent Desseaux) Site Adresse Réseau Masque de sous réseau Orsay Bayonne Sophia Antipolis Bruxelles Itinérant DMZ d Orsay Plan d adressage des sous réseaux par site Type de direction Adresse de sous réseau Vlan ID Orsay Vlan ID Bayonne Vlan ID Sophia Antipolis Vlan ID Bruxelles Serveurs 172.X.0.0/24 Vlan 2 Vlan 102 Vlan 202 Vlan 302 Générale 172.X.1.0/24 Vlan 3 Vlan 103 Vlan 203 Vlan 303 Administrative 172.X.2.0/24 Vlan 4 Vlan 104 Vlan 204 Vlan 304 et Financière Commerciale et 172.X.3.0/24 Vlan 5 Vlan 105 Vlan 205 Vlan 305 Marketing Etudes 172.X.4.0/24 Vlan 6 Vlan 106 Vlan 206 Vlan 306 Production 172.X.5.0/24 Vlan 7 Vlan 107 Vlan 207 Vlan 307 (X varie en fonction du site) 3. Configuration d un serveur DHCP (Vincent Desseaux) La configuration d un serveur DHCP est renseignée dans le fichier dhcpd.conf. Dans cette partie, nous étudierons les différents paramètres et déclarations courants au bon fonctionnement de ce service par le biais d extraits de la configuration DHCP du site d Orsay. Avant d entamer l étude de ces extraits, quelques généralités sur ces deux points : Les déclarations sont utilisées pour décrire la topologie du réseau, les clients et les adresses attribuables, ou encore pour appliquer un groupe de paramètres à un groupe de déclarations. Dans tout groupe de paramètres et de déclarations, les paramètres doivent être spécifiés avant les déclarations qui en dépendent. Les paramètres déterminent les valeurs internes du serveur (par exemple la durée d un bail), définissent son comportement (ce que dhcpd doit attribuer des adresses aux clients inconnus) et spécifient les informations qu'il doit fournir aux clients (tel que la passerelle). La RFC 2132 (DHCP Options and BOOTP Vendor Extensions) définit les options standards et donc les plus couramment utilisé. Les paramètres débutant avec le mot-clé option sont réellement optionnels pour DHCP. Les autres paramètres contrôlent soit le comportement du serveur DHCP, soit spécifient des paramètres obligatoires des clients DHCP (par exemple le nom du serveur) Annexes 69

70 Les baux alloués sont renseignés dans le fichier dhcpd.leases (peut être dans /var/lib/dhcpd.leases ou /etc/dhcpd/dhcpd/leases en fonction des versions). Nous pourrons trouver en autre dans ce fichier pour chaque adresse allouée : La date de début et de fin du bail L adresse MAC de l hôte L adresse IP allouée Des options propres aux clients (nom d hôte par exemple) # ======== Option Generales du dhcp ======== server-name "ors-srv-dhcp1.vsn-aristote.lan"; #Nom du serveur DHCP employé option domain-name "vsn-aristote.lan"; #Option définissant le suffixe DNS employé (optionnel) option domain-name-servers , ; #Option définissant les adresses IP des serveurs DNS ping-check = 1; #Evalue si l'adresse est déjà attribuée en effectuant un ping de celle-ci default-lease-time 3600; #Durée par défaut du bail (en secondes) max-lease-time 7200 ; #Durée max du bail (en secondes) authoritative; #Définit le serveur comme faisant autorité sur le segment auquel il est connecté log-facility local7; #Définit la redirection des messages de log # ======== Déclaration Des Reseaux ======== #Déclaration du réseau partagé Orsay pour informer le serveur DHCP que certains sous-réseau IP partagent en réalité le même réseau physique shared-network Orsay { #Déclaration sous réseau /24 subnet netmask { #Nous pourrions définir pour un réseau spécifique une option différente que celle employée dans la partie générale #option domain-name "mon_domaine.qqc"; option broadcast-address ; #Définition de l adresse de diffusion option routers ; #Définition de la passerelle par défaut pool { # Déclaration d'une plage d'attribution d'adresse range ; #Définition de l étendue de la plage, ici l attribution commencera à partir de l adresse /24 pour finir à l adresse /24, soit 151 adresses. } } subnet netmask { option broadcast-address ; option routers ; pool { range ; } } } Annexes 70

71 1. Configuration du canal failover du site d Orsay : # ======== Failover configuration ======== failover peer "dhcp-failover" { #Déclaration du canal failover ayant pour nom "dhcp-failover" primary; #Spécifie pour le fichier de configuration qu il est maître (secondary pour secondaire) address ; #L adresse d écoute de l hôte locale port 647; #Port d écoute de l hôte locale peer address ; #L adresse d écoute de l hôte distant peer port 647; #Port d écoute de l hôte distant max-response-delay 30; #Temps maximum de non-réponse d une des paires avant rupture du canal max-unacked-updates 10; #Nombre maximum de mise à jour d une paire sans avoir reçu d acquittement load balance max seconds 3; #Temps maximum avant lequel l une des paires répond à une requête prévu à l autre si aucune réponse n a été envoyé (Seulement sur le maître) mclt 1800; #Définit le temps maximum pour lequel un bail peut être renouvelé sans en informer la paire (Seulement sur le maître) split 128; #Définit la proportion de répartition entre les deux serveurs (128 équivaut à 50%) (Seulement sur le maître) } Ensuite lors de la configuration des sous-réseaux et des plages, il faudra spécifier le nom du canal failover à utiliser : subnet netmask { option broadcast-address ; option routers ; pool { failover peer "dhcp-failover"; #Définit que ce canal failover gère la répartition de charge pour la plage donnée range ; } ping-check = 1; } 2. Mise en place de la fonctionnalité de mise à jour du DNS La mise en place de cette fonctionnalité se fait en renseignant dans le fichier dhcpd.conf les parties suivantes : # Spécifie la zone de nom sur lequel DHCP effectuera les mises à jours ddns-domainname "vsn-aristote.lan"; # Spécifie la zone reverse sur lequel DHCP effectuera les mises à jours pour chaque réseaux/sous-réseaux. ddns-rev-domainname " in-addr.arpa"; ddns-rev-domainname " in-addr.arpa"; ddns-rev-domainname " in-addr.arpa"; #Méthode de mise à jour du DNS : soit ad-hoc (Obsolète car supporte pas le failover), soit interim ddns-update-style interim; #Mise à jour autorisée ddns-updates on; #on force la maj par le dhcp et non par le client ignore client-updates; #on force la maj des statiques DHCP update-static-leases on; # Autoriser les clients inconnus au niveau de l'adresse MAC allow-unknow-clients; Annexes 71

72 3. Les aspects sur la sécurité Le serveur DNS doit être configuré pour pouvoir être mis à jour par le serveur DHCP. La méthode la plus sûre utilise les signatures TSIG, basées sur une clé comme pour le programme d'administration des serveurs de nom rndc.. Nous devrons en créer pour effectuer les mises à jour DNS depuis le(s) serveur(s) DHCP via la commande «dnssec-keygen -a hmac-md5 -b <bitlength> -n HOST <key-file-name>». Cette commande va générer deux fichiers nommés K<hostname>.xxxxxxxx.key et K<hostname>.xxxxxxxx.private, le fichier.key va devenir notre clef rndc. Dans le fichier de configuration named.conf et dhcpd.conf, il faudra renseigner la/les clé(s) TSIG à utiliser. # Clef partagee dhcpd et bind9 key <nom de la clé> { algorithm hmac-md5; secret <ICICOLLERLACLEFSECRETEGENEREE>; }; Pour mettre à jour la/les zone(s) directe et reverse(s) par DHCP, il convient de renseigner dans le fichier named.conf (donc bind) la déclaration allow-update { key <Nom de la clé>; } pour chacune des zones concernées. Annexes 72

73 4. Déroulement du service DHCP DHCP Discover : Demande du client d une découverte des serveurs DHCP disponible par celui-ci et demande une première configuration IP. Le client émet un message de demande de bail IP (paquet DHCP Discover) qui est envoyé sur le réseau avec adresse IP source et adresse IP destination DHCP Offer. DHCP Offer : Réponse du/des serveur(s) au message DHCP Discover du client qui contient les premiers paramètres de configuration IP. Le(s) serveur(s) DHCP réponde(nt) en proposant une adresse IP en fonction des paramètres renseignés dans le fichier «dhcpd.conf», avec une durée de bail et l'adresse IP du serveur DHCP par le paquet DHCP Request : Requête du client afin de demander/renouveler son bail pour la configuration IP. Le client sélectionne le premier paquet DHCP Offer (s'il y a plusieurs serveurs DHCP) reçue et envoie une demande d'utilisation de cette adresse au serveur DHCP par la trame DHCP Request. Son message comporte l'identification du serveur sélectionné, qui permet d informer au serveur DHCP concerné que son offre a été retenue. Tous les autres serveurs DHCP reçoivent également ce paquet et retirent donc leurs offres. DHCP ACK : Réponse du serveur qui valide le bail et lui transmet l intégralité de sa configuration IP. Le serveur DHCP sélectionné accuse la réception de la demande précédente et accorde l'adresse en bail via le paquet DHCP ACK, celui-ci contient également des informations supplémentaires comme le serveur DNS par défaut ou le nom du domaine par exemple. Ce bail est ensuite enregistré par le serveur DHCP dans le fichier «dhcdp.leases» qui regroupe l ensemble des baux affectés par celui-ci. *Notons que l ensemble des messages DHCP évoqués sont tous diffusés. D autres requêtes DHCP existent également, dont une présentation succincte est faite ci dessous : Nom DHCP Decline DHCP NAK DHCP Release DHCP Inform Description Le client annonce au serveur que l adresse proposée par le DHCP Offer est déjà utilisée Réponse du serveur pour signaler au client que son bail est échu, ou si le client annonce une mauvaise configuration. Le client libère son adresse IP Le client demande des paramètres locaux, il a déjà son adresse IP Annexes 73

74 5. Relais DHCP No Source Destination Protocol Info DHCP DHCP Discover DHCP DHCP Offer DHCP DHCP Request DHCP DHCP ACK Capture sur /24 No Source Destination Protocol Info DHCP DHCP Discover DHCP DHCP Offer DHCP DHCP Request DHCP DHCP ACK Capture sur /24 1. Mise en place d un relai DHCP Avant de mettre en place le relai DHCP sur un serveur, il convient de vérifier que celui-ci supporte bien le protocole 802.1q et que les sous interfaces soient bien configurés pour chaque sous réseau. # find /lib/modules/`uname -r` -name 8021q //Vérifie que le module 8021q est bien présent dans le noyau de la distribution Linux # modprobe 8021q //charge le module permettant la prise en charge des trames taggés # aptitude install vlan //installation de l outil de configuration de VLAN # vconfig add <interface> <N Vlan> //permet d ajouter une sous interface prenant en charge le N de VLAN donné pour une interface donnée # ifconfig eth0.<n Vlan> <172.X.Y.Z/24> //configuration IP de la sous interface Une fois les sous interfaces créées et affectées au bon Vlan, nous pouvons entamer l installation et la configuration du relai DHCP. Ce dernier point s établit via le fichier dhcp3-relay comme suit : # Adresses des serveurs DHCP auquel seront transféré les requêtes SERVERS=" " # Définit les interfaces d écoute (Si aucune interface renseignée, alors toute les interfaces sont utilisés) INTERFACES="" # Définit les options additionnelles (se référer au manuel de dhcp3-relay) OPTIONS="" Annexes 74

75 6. Fichiers de configuration dhcpd.conf Orsay [ORS-SRV-DHCP1] #sample dhcpd.conf file # ======== Option Generales du dhcp ======== server-name "ors-srv-dhcp1.vsn-aristote.lan"; option domain-name "vsn-aristote.lan"; option domain-name-servers , ; ping-check = 1; default-lease-time 3600; max-lease-time 7200; authoritative; log-facility local7; # ======== Failover configuration ======== failover peer "dhcp-failover-orsay" { primary; # declare this to be the primary server address ; port 647; peer address ; peer port 647; max-response-delay 30; max-unacked-updates 10; load balance max seconds 3; mclt 1800; split 128; } failover peer "dhcp-failover-bayonne" { secondary; # declare this to be the primary server address ; port 647; peer address ; peer port 647; max-response-delay 30; max-unacked-updates 10; } include "/etc/dhcp3/dhcpd.master.orsay"; include "/etc/dhcp3/dhcpd.master.bayonne"; Orsay [ORS-SRV-DHCP2] #sample dhcpd.conf file # ======== Option Generales du dhcp ======== server-name "ors-srv-dhcp2.vsn-aristote.lan"; option domain-name "vsn-aristote.lan"; option domain-name-servers , ; default-lease-time 3600; max-lease-time 7200; ping-check = 1; authoritative; log-facility local7; # ======== Failover configuration ======== failover peer "dhcp-failover-orsay" { secondary; # declare this to be the primary server address ; port 647; peer address ; peer port 647; max-response-delay 30; max-unacked-updates 10; } include "/etc/dhcp3/dhcpd.master.orsay"; Annexes 75

76 7. dhcpd.master.orsay # ======== Mise a jour DDNS ======== ddns-domainname "vsn-aristote.lan"; ddns-rev-domainname " in-addr.arpa"; ddns-rev-domainname " in-addr.arpa"; ddns-rev-domainname " in-addr.arpa"; ddns-rev-domainname " in-addr.arpa"; ddns-rev-domainname " in-addr.arpa"; ddns-rev-domainname " in-addr.arpa"; ddns-update-style interim; ddns-updates on; ignore client-updates; update-static-leases on; key dhcpupdate { algorithm hmac-md5; # secret ICICOLLERLACLEFSECRETEGENEREE; }; zone in-addr.arpa. { primary ; key dhcpupdate; } zone in-addr.arpa. { primary ; key dhcpupdate; } zone in-addr.arpa. { primary ; key dhcpupdate; } zone vsn-aristote.lan. { primary ; key dhcpupdate; } # ======== Reseaux ======== shared-network Orsay { subnet netmask { option broadcast-address ; option routers ; pool { range ; failover peer "dhcp-failover-orsay"; } } subnet netmask { option broadcast-address ; option routers ; pool { range ; failover peer "dhcp-failoverorsay"; } } subnet netmask { option broadcast-address ; option routers ; pool { range ; failover peer "dhcp-failoverorsay"; } } } Annexes 76

77 4. Configuration du DNS BIND9 (Rudy Promé) 1. Configuration serveur Maître Fichier name.conf On y spécifie le nom de domaine de notre client et le fichier contenant les enregistrements de la zone, ainsi que quelques options. Fichier de zone vsn-aristote.lan.hosts Voici donc le fichier de zone créé manuellement. Dans les hôtes enregistrés manuellement, on y ajoutera les quatre serveurs DNS Esclaves via un enregistrement NS comme pour l enregistrement du serveur Maître ci-dessus. On peut également ajouter des Alias via un enregistrement CNAME. Annexes 77

78 2. Configuration serveur Esclave On retrouve la même méthode pour l installation. La configuration quant à elle s avère quelque peu différente puisqu il faut lui indiquer qu il dépend du serveur Maître. Sur le serveur Esclave, dans le fichier /etc/bind/named.conf.local, on lui indique qu il est donc Esclave et qu il doit importer les zones du serveur Maître comme suit : Zone «vsn-aristote.lan» { Type slave ; File «vsn-aristote.lan.hosts ; Masters { ; } ; } ; // Nom de la zone // On lui indique qu il est Esclave // Quel est le fichier de zone // Il importe les zones du serveur Maître On l autorise ensuite à renvoyer des notifications vers le serveur Maître en ajoutant la ligne suivante dans le fichier /etc/bind/named.conf.options : allow-notify { ; } ; Côté Maître, il y a également des modifications à effectuer pour lui informer qu il doit mettre à jour son serveur Esclave dynamiquement. Lors de l étape précédente, nous avons autoriser l envoie de notifications depuis le serveur Esclave, il faut donc sur le serveur Maître autoriser les notifications. Dans /etc/bind/named.conf, dans la zone correspondante on ajoute la fonction «notify yes ;». Dans le fichier de zone vsn-aristote.lan.hosts, on ajoute l enregistrement du serveur DNS Esclave. Enfin, on ajoute une ligne dans le fichier /etc/bind/named.conf.options qui permet d autoriser le transfert de zone : allow-transfer { ; } ; (adresse IP du serveur Esclave d Orsay). 3. Phases de tests DNS Après la configuration des serveurs et des postes clients, pour s assurer du bon fonctionnement des serveurs Bind9, nous avons à notre disposition plusieurs commandes Unix. La commande Ping : ping nomdelamachine. Permet de tester la résolution du nom. La commande Nslookup : nslookup nomdelamachine. Permet également de test la résolution du nom et renseigne quel serveur DNS a été utilisé. La commande Dig : dig nomduserveur. Permet d interroger les serveurs Bind et obtenir des informations. Annexes 78