Année : 2016-2017

PROJET INFRASTRUCTURESYSTEME/RESEAU

Groupe 2 : Calmel Marie - Dadolle Robin - Mourier Romain - Serbiladze Serge

INFRASTRUCTURE 1
TABLE DES MATIERES

Introduction ..................................................................................................................................................................... 3
I) Schéma technique ........................................................................................................................................................ 3
II) Choix techniques ......................................................................................................................................................... 4
1) Isolation pour les différents types d'utilisateurs/usages ................................................................................. 4
2) Gestion et authentification des utilisateurs/trices .......................................................................................... 4
3) Attributtion des adresses IP .............................................................................................................................. 5
4) Gestion des noms .............................................................................................................................................. 5
5) Serveur WEB....................................................................................................................................................... 5
6) Accès distants..................................................................................................................................................... 5
7) Gestion des données ......................................................................................................................................... 6
III) Pistes d'améliorations ................................................................................................................................................ 6
1) FreeRadius .......................................................................................................................................................... 6
2) Authentification 802.1x ..................................................................................................................................... 6
3) Sauvegarde ......................................................................................................................................................... 6
4) Améliorations générales .................................................................................................................................... 7

INFRASTRUCTURE 2
INTRODUCTION

C'est dans le cadre de la réponse à un cahier des charges proposant la refonte du système informatique de CPE
que notre travaille s'articule.

Le but de ce document est de présenter de manière simple et concise les différentes briques et choix techniques
que nous avons fait au cours de la réalisation de ce projet.

I) SCHEMA TECHNIQUE

INFRASTRUCTURE 3
Comme nous pouvons le voir sur ce schéma, l'architecture reste extrêmement simple niveau matériel. Une
grande isolation et séparation se fait via les VLANs. Néanmoins pour prévenir les pannes, tous les éléments
critiques du réseau sont redondés : deux routeurs WAN, suivit par deux firewalls, sur lesquels la charge réseau se
répartis de manière automatique à l'aide du protocole HSRP : 3 VLANs passent par défaut sur l'un des pare-feu
pour sortir vers l'extérieur, et 4 autres sur l'autre routeur. Néanmoins lorsque l'un tombe en panne, HSRP
permet de faire passer tout le trafic sur le même routeur.

Les commutateurs sont aussi redondés pour plus de sécurité. Nous n'avons représenté ici que les commutateurs
du cœur de réseau par simplification, néanmoins il faut imaginer un étage de commutation d'accès entre les
équipements finaux (serveurs) et cet étage de commutateurs cœur de réseau.

II) CHOIX TECHNIQUES

Afin de satisfaire le cahier des charges initiales, toutes les briques de notre infrastructure sont Open source voir
libres.

1) ISOLATION POUR LES D IFFERENTS TYPES D'UTILISATEURS/USAGES

Plutôt qu'une isolation physique très couteuse par chacun des réseaux associés aux différents usages, nous
avons préféré mutualiser les équipements et se servir de la technologie des VLANs. Ceci permet de simuler la
présence de plusieurs réseaux Ethernet complètement séparés tout en utilisant les mêmes commutateurs. Il a
été décidé de reprendre les VLANs existant sur le début du projet 7 VLANS :

VLAN étudiants : postes des clients.

VLAN administratif : poste des clients.

VLAN Libre services : poste des clients nécessitant une authentification avant d'accéder au réseau : Wifi par
exemple.

VLAN Private : les serveurs les plus critiques comme ceux gérant l'authentification.

VLAN DMZ publique : Les serveurs accessibles depuis Internet.

VLAN DMZ Private : Les serveurs hébergeant des services pour les utilisateurs internes.

VLAN Stockage : le stockage.

La séparation entre la zone Private et la zone DMZ privée peut sembler assez flou, surtout actuellement. Il y a
quelques modifications qu'il faudrait faire, par exemple laisser les contrôleurs de domaine dans le VLAN Private,
mais faire les partages réseaux sur d'autres serveurs qui eux seraient dans le VLAN DMZ privée.

2) GESTION ET AUTHENTIFICATION DES UTILISATEURS/TRICES

La gestion des utilisateurs est centralisée. Elle repose entièrement sur deux contrôleurs de domaine Samba,
l'utilisation de samba étant fixé par le cahier des charges lui-même. Ces deux serveurs étant des réplications l'un
de l'autre, ceci nous permet d'avoir une certaine tolérance aux pannes, ce qui est primordial pour un service
aussi critique. Les contrôleurs de domaine reposent sur un annuaire LDAP permettant de stocker toutes les
informations relatives aux domaines configurées : machines, utilisateurs, forêt DNS.

Un autre serveur vient s'ajouter pour l'identification et l'authentification des utilisateurs au niveau du réseau : le
serveur radius. Il permet d'identifier les utilisateurs très tôt pour éventuellement attribut la bonne ressource à
l'utilisateur. Il sera utilisé pour l'authentification 802.1x au niveau des commutateurs, ou pour la connexion au
VPN éventuellement lorsqu'il sera en lien avec les contrôleurs de domaine.

INFRASTRUCTURE 4
Nous avons choisi FreeRadius parce que c'est une implémentation très connue et très utilisées, ceci donnant
donc accès à une grande quantité de documentations et aides diverses sur Internet.

Le serveur FreeRadius permet de gérer l'authentification, l'autorisation et l'accounting. Il met en œuvre une
authentification PEAP. La gestion des certificats et clefs privées se faire à l'aide d'une PKI propre à ce serveur.
L'authentification est protégée par un tunnel TLS. Les certificats en sont utilisés que coté serveur, parce que c'est
plus facile à déployer que EAP-TLS. L'identification se fait via MS-CHAPv2 supporté nativement par beaucoup de
choses et notamment depuis Microsoft Windows SP4 et Mac OS 10.3.

Enfin le portail captif permet d'authentifier les machines non gérées par CPE qui voudraient se connecter au
réseau. Ceci permet de vérifier que ce sont bien des utilisateurs légitimes, par exemple sur le Wifi. Ce portail
captif utilise le serveur Radius pour faire cette authentification.

3) ATTRIBUTTION DES ADRESSES IP

L'attribution des adresses IP se fait de manière statique sur tous les serveurs, pour des raisons de sécurité : nous
ne voudrions que plus aucun serveur n'ait d'adresse IP à cause de la panne d'un serveur DHCP.

Pour les clients, l'attribution des adresses IP se fait à l'aide d'un serveur DHCP. Ce serveur n'est pas présent dans
les VLANS qui en ont besoin, mais il se trouve plutôt dans la DMZ privée. Les routeurs sont configurés pour faire
relai DHCP et envoyer les demandes DHCP qu'ils voient au serveur en question.

Ceci permet d'avoir un seul serveur DHCP qui va gérer toutes les plages dynamiques, tout en gardant la machine
dans un seul VLANs, pour une meilleure isolation.

Nous avons choisi isc-dhcpd, parce que c'est très commun sur les serveurs DHCP sous Linux.

4) GESTION DES NOMS

La gestion des noms des machines et des différents domaines se fait directement sur les contrôleurs de
domaine. Néanmoins nous avons fait le choix de ne pas utiliser le serveur DNS directement intégré à Samba.
Effectivement après plusieurs recherches ils se trouvent que ce serveur est en fait assez limité et ne permet de
faire que des choses simples. Le cahier des charges n'étant pas particulièrement descriptif sur les besoins en
termes de gestion DNS, nous avons préféré utiliser un backend Bind9.

Samba va continuer de gérer les zones DNS, de mettre à jour les différents enregistrements, mais c'est le très
classique Bind9 qui fera office de serveur DNS, sur les deux contrôleurs de domaine. Ceci nous permet à la fois la
gestion simple et centralisées par Samba, tout en gardant la possibilité de faire des choses plus avancées via
Bind9 si le besoin se fait sentir.

5) SERVEUR WEB

Nous avons choisi d'utiliser le serveur Apache2 pour répondre à ce besoin. Effectivement ce besoin n'étant pas
très détaillé dans le cahier des charges, nous avons choisi un serveur web qui sait faire beaucoup de choses que
ça soit en web statique ou en web dynamique. Ceci répondant normalement à la très grande majorité des
besoins qui pourraient se présenter. De plus c'est un serveur très utilisé donc très bien documenté.

6) ACCES DISTANTS

Les accès distants se font par l'intermédiaire d'un serveur VPN. Le but est de fournir un accès sécurisé aux
ressources internes à des personnes qui ne sont pas présentes physiquement. Il s'agit donc d'un tunnel entre
l'infrastructure de CPE et la machine du client qui cherche à se connecter.

INFRASTRUCTURE 5
Pour répondre à ce besoin nous avons décidé de nous orienter vers OpenVPN. C'est une solution très rependue
pour faire des VPN SSL, les avantages principaux étant que c'est très facile à mettre en place, et à utiliser coter
client. Mais c'est aussi compatible avec une grande variété de système d'exploitation, permettant ainsi au plus
grand nombre de pouvoir se connecter.

Le serveur VPN va authentifier les utilisateurs grâce aux contrôleurs de domaine, et va ensuite gérer par lui-
même les différentes ressources auxquels aura accès l'utilisateur. Il va assigner une adresse IP pour le client dans
le tunnel et ensuite les communiquer différents paramètres réseaux : serveurs DNS à utiliser, les routes des
différents réseaux joignables. Il faudra néanmoins mettre en place un firewall sur cette machine, de façon à
filtrer les flux autorisés ou non.

7) GESTION DES DONNEES

La gestion du stockage se fait dans le VLAN éponyme à l'aide d'un NAS FreeNAS. C'est une solution toute
intégrée et assez facile à mettre en œuvre. Dans le cas présent, le NAS sert juste à faire des partages NFS qui
sont utilisées sur les différentes machines qui ont besoin de garder des quantités assez importantes de données
et/ou des données que l'on ne peut pas se permettre de perdre : les données des utilisateurs par exemple. Les
partages réseaux et le serveur web utilisent un partage NFS par exemple.

La solution n'est pas idéale, surtout au niveau des partages réseaux pour les utilisateurs, puisque cette technique
ne permet pas d'utiliser les droits avancés sur les fichiers, nous pouvons néanmoins proposer une amélioration à
ça avec plus de temps.

Le deuxième point important dans cette gestion des données et la gestion des backups. Les backups sont gérés
par un serveur à part, qui n'utilise pas le NAS comme support de stockage, tout est vraiment séparé de
l'infrastructure de production à ce niveau-là, de façon à ce que l'on ne puisse pas perdre à la fois les backups et à
la fois les données parce qu'un NAS vient de prendre feu.

Pour l'instant les backups sont gérés de manières assez simplistes : c'est un script bash qui s'exécute chaque jour
et qui sauvegarde les données voulues sur chaque machine à l'aide de rsync utilisant SSH. Cette solution permet
de versionner les sauvegarde et de les garder durant 7 jours.

III) PISTES D'AMELIORATIONS

Il y a certaines choses assez évidentes à faire pour améliorer ce que nous avons fait mais où le temps à manquer.

1) FREERADIUS

Actuellement FreeRadius utilise des utilisateurs locaux pour son authentification. Il était prévu de faire en sorte
que cette authentification repose sur les contrôleurs de domaines, le but étant d'utiliser une seule base
d'utilisateur centralisée.

2) AUTHENTIFICATION 802.1X

Actuellement cette authentification n'est pas utilisée à son plein potentiel. Effectivement, nous aurions pu
généraliser ce type d'authentification au niveau du réseau de façon à gérer l'attribution des ports dans les bons
VLANs de manière dynamique en fonction de l'utilisateur qui se logue sur le PC en question.

3) SAUVEGARDE

La sauvegarde est pour l'instant très basique et pas adapté pour toutes les situations, notamment si un jour un
serveur Windows est utilisé. L'une des pistes d'amélioration les plus évidentes serait d'utiliser une vraie solution

INFRASTRUCTURE 6
de backup telle que Bacula par exemple, qui permettrait de gérer plus facilement les sauvegardes mais aussi
d'avoir une politique de rétention des données plus complexe.

Il serait néanmoins possible d'améliorer ce dernier point en écrivant un script un tout petit peu plus complexe.

4) FREENAS

Joindre le domaine avec FreeNas de façon à ce que les utilisateurs se connectent directement dessus pour les
partages réseaux. Ce qui permet d'utiliser la gestion des droits avancées sur les fichiers.

5) AMELIORATIONS GENERA LES

Augmenter la redondance et la tolérance aux pannes. Dans le cas présent beaucoup de services ne sont pas
redondés.

Mettre en place de l'IPv6. CPE est une organisation assez ancienne ce qui fait qu'elle a beaucoup d'adresse IPv4
publique de disponibles, au point d'adresser des postes utilisateurs directement avec. Néanmoins il pourrait être
une bonne idée de commencer à se tourner vers cette technologie qui va devenir indispensable dans les années
à venir.

Actuellement OpenVPN et Freeradius utilise leurs propres PKI, utilisés de manière indépendante l'une de l'autre,
simplement pour simplifier la gestion des différents certificats. Il serait une bonne idée de créer une seule et
unique PKI pour créer et gérer les tous les besoins en certificats et autres clefs privées pour toute l'organisation.

Mise en place d'un serveur de synchronisation de temps (NTP) : c'est tout simplement indispensable pour des
contrôleurs de domaine en production, les tickets délivrés par Kerberos étant dépendants de l'heure.

INFRASTRUCTURE 7