Projet Système & Réseau

Transcription

1 Olivier Raulin CSII3 Epsi Nantes Projet Système & Réseau Mise en place d une infrastructure systèmes et réseaux Ce document a pour but d expliquer la démarche de recherche, et d expliquer les choix techniques qui auront été faits afin de mettre en place l architecture décrite dans le sujet. L accent sera mis, dans la mesure du possible, sur l utilisation de solutions libres, permettant, dans certains cas, un challenge technique, tout en conservant un maximum de souplesse, en limitant l impact financier lié aux licences logicielles. Au vu de la complexité du projet, de la répétitivité de certaines tâches, du temps accordé, et du nombre de cours qui n ont pas pu être suivis, tous les sujets ne seront pas forcément complètement fonctionnels, et/ou des manques dans la configuration pourront se sentir. Globalement, j ai essayé de rendre l infrastructure la plus fonctionnelle possible, comme vous pourrez, je l espère de la meilleure manière possible, le voir sur les différentes vidéos, uploadées sur la plateforme DailyMotion, dans l ordre :

2 I Interconnexion des sites Afin de simuler une bande passante symétrique de 2mbps, l utilisation de la QoS présente dans le noyau Linux sera utilisée. Afin de simplifier l installation, cette machine fera office de routeur et de solution de VPN via IPSec. OpenSwan sera mis en œuvre à cet effet (note : absent lors de la visio, je n ai pas pu la rattraper) /etc/ipsec.conf: #/etc/ipsec.conf- OpenswanIPsecconfigurationfile # Thisfile: /usr/share/doc/openswan/ipsec.conf-sample # # Manual: ipsec.conf.5 version 2.0 # conformstosecondversionofipsec.confspecification # basicconfiguration configsetup nat_traversal=yes # excludenetworksusedonserversidebyadding%v4:!a.b.c.0/24 virtual_private=%v4: /8,%v4: /16,%v4: /12,%v4:! /24,%v6:fc00::/7 # OEisnowoffbydefault. Uncommentandchangetoon, toenable. oe=off # whichipsecstacktouse. autowilltrynetkey, thenklipsthenmast protostack=netkey interfaces=%"defaultroute" # Addconnectionshere connprojetreseau type=tunnel authby=secret left= right= leftsubnets={ / /24} rightsubnet= /24 auto=start connprojetreseauv6 connaddrfamily=ipv6 type=tunnel authby=secret

3 left=fd00:dead:beef:3::1 right=fd00:dead:beef:3::2 leftsubnets={fd00:dead:beef:1::/64fd00:dead:beef::/64} rightsubnet=fd00:dead:beef:2::/64 auto=start /etc/ipsec.secrets include/var/lib/openswan/ipsec.secrets.inc : PSK "0xe6cf42f0_84f90d68_587a782f_913306f8_43b2b779_6201fe50_107621a5_2d9024f8" fd00:dead:beef:3::1fd00:dead:beef:3::2: PSK"SECRET" Pour la QoS, la commande Linux tc sera utilisée tcqdiscadddeveth1roothandle1: htbdefault1r2q160 tcclassadddeveth1parent1: classid1:1htbrate2048kbit iptables -t mangle -A POSTROUTING -o eth1 -m mark -j CLASSIFY --set-class 1:1 --mark 0x12 II Infrastructure serveur Les fonctionnalités attendues dans ce projet sont : Un contrôleur de domaine Afin de rendre ce service, il est possible d utiliser, au choix, un serveur de type Windows Server, ou un serveur Linux avec le service Samba configuré correctement (utilisant Kerberos, LDAP, etc.) Mon choix se portera pour la version 4 de samba, très récente, pour son support de la fonctionnalité de stratégies de groupe, et pour le défi technique qu impose une version fraîchement sortie (compilation des sources, etc) Nous considérerons qu il existe 3 types de matériels utilisés par les employés au sein de l entreprise : des ordinateurs de bureau ; des ordinateurs portables ; des tablettes / smartphones (qu il ne sera cependant pas possible de simuler).

4 On imaginera que ces différents matériels utilisent des systèmes différents, comme par exemple des machines Windows, Linux, et MacOS, ainsi que des appareils Apple, Android ou BlackBerry. Nous testerons uniquement des clients Windows PC, dans sa version XP, pour des raisons de consommation mémoire (machine physique assez limitée) et de charge de travail nécessaire à des tests plus poussés Les choix techniques prennent en compte ces différents matériels, et font en sorte que ceux ci puissent fonctionner dans des conditions optimales. smb.conf # Globalparameters [global] workgroup=projetreseau realm=projetreseau.local netbiosname=samba serverrole=activedirectorydomaincontroller [netlogon] path=/usr/local/samba/var/locks/sysvol/projetreseau.local/scripts readonly=no [sysvol] path=/usr/local/samba/var/locks/sysvol readonly=no [test] path=/share/test readonly=no public=yes krb5.conf [libdefaults] default_realm=projetreseau.local dns_lookup_realm=false dns_lookup_kdc=true projetreseau.local.zone $ORIGINprojetreseau.local. INSOA samba hostmaster( ; serial 2D ;refresh 4H ;retry

5 6W ;expiry 1W) ;minimum INNS samba INAAAA fd00:dead:beef::1 INA IN MX 10 mail mail IN MX 10 mail samba INAAAA fd00:dead:beef::1 samba INA gc._msdcs INA gc._msdcs INAAAA fd00:dead:beef::1 06a7f8ee-59c b075-10a818fc2ccc._msdcs INCNAME samba ; ; globalcatalogservers _gc._tcp INSRV samba _gc._tcp.default-first-site-name._sites INSRV samba _ldap._tcp.gc._msdcsinsrv samba _ldap._tcp.default-first-site-name._sites.gc._msdcs INSRV samba ; ; ldapservers _ldap._tcp INSRV samba _ldap._tcp.dc._msdcsinsrv samba _ldap._tcp.pdc._msdcs INSRV samba _ldap._tcp.45f4bae d f8e.domains._msdcs IN SRV samba _ldap._tcp.default-first-site-name._sites INSRV samba _ldap._tcp.default-first-site-name._sites.dc._msdcs INSRV samba ; ; krb5servers _kerberos._tcp INSRV samba _kerberos._tcp.dc._msdcs INSRV samba _kerberos._tcp.default-first-site-name._sites INSRV samba _kerberos._tcp.default-first-site-name._sites.dc._msdcs INSRV010088samba _kerberos._udp INSRV samba ; MITkpasswdlikestolookupthisnameonpasswordchange _kerberos-master._tcp INSRV samba _kerberos-master._udp INSRV samba ; ;kpasswd _kpasswd._tcp INSRV samba _kpasswd._udp INSRV samba ; ; heimdal'findrealmforhost' hack _kerberos INTXTPROJETRESEAU.LOCAL

6 proxy IN A proxy IN AAAA fd00:dead:beef:1::10 mail IN A mail IN AAAA fd00:dead:beef:1::11 voip IN A voip IN AAAA fd00:dead:beef:1::12 web IN A web IN AAAA fd00:dead:beef:1::13 samba IN A samba IN AAAA fd00:dead:beef:0::1 samba-priin A samba-priin AAAA fd00:dead:beef:2::2 gw-bdx IN A gw-bdx IN AAAA fd00:dead:beef:1::ffff samba-pri IN A samba-pri IN AAAA fd00:dead:beef:2::1 sugar IN CNAME web Un serveur de fichiers Ici, nous avons deux solutions qui se profilent, notamment entre un système Windows et un système Linux. Le système Windows a l avantage de la simplicité de configuration, puisqu un rôle de serveur de fichiers peut se mettre en place très simplement. Cependant, le coût de la licence, non nécessairement justifié pour ce type d usage est un frein à son utilisation, et la stabilité du système reste contestée dans le monde de l informatique. Un système Linux aura l avantage de pouvoir fonctionner sur une machine plus modeste, ne nécessitera pas l achat d une licence, et sera pleinement compatible avec les machines Windows Linux et MacOS présentes dans l entreprise, via la configuration de Samba et de NFS Samba (partage CIFS) Samba sera utilisé afin d assurer la compatibilité avec les systèmes Microsoft. Les machines Linux et MacOS sont capables demonter des systèmes de fichiers SAMBA.

7 (Voir smb.conf en partie précédente) Un accès à Internet limité à quelques protocoles L accès Internet doit se limiter à l accès HTTP, HTTPS et FTP. Plusieurs solutions se profilent ici, avec notamment : Le filtrage via Netfilter Il est effectivement possible de filtrer, via Netfilter, les protocoles autorisés à sortir de l entreprise. Cependant, la maintenance deviendrait très rapidement complexe, et nécessitera une étude potentiellement assez poussée afin de pouvoir se voir apporter des modifications. De plus, il faut penser aux obligations légales de l entreprise, qui font que tout accès à un site Internet puisse être identifié, avec l identité de la personne, la date et l heure de connexion, et le site visité. Cela n est pas directement possible via Netfilter. L utilisation d un proxy L utilisation d un proxy apporte plusieurs avantages : plus de sécurité ; une configuration plus aisée à réaliser et à maintenir ; la possibilité de restreindre plus finement les protocoles (par exemple, allouer un débit maximal à un site web gourmand, par exemple) et les usages (limitation du débit pour un utilisateur très consommateur, etc.) ; l identification éventuelle de qui a visité quel site (ou du poste qui a servi à consulter le site web), dans un but légal de conservation des logs ; de cache pour le web, permettant une accélération du chargement des pages et une diminution de l utilisation de la bande passante. Cette solution sera retenue, et c est le projet libre Squid qui sera retenu, pour sa robustesse et sa réputation. Il aurait été possible de lui rajouter squidguard, qui permet de gérer plus finement quels sites sont autorisés et/ou bloqués, mais faute de temps, celui ci ne sera pas implémenté. squid.conf aclsafe_portsport80 aclsafe_portsport443 aclsafe_portsport21 #HTTP #HTTPS #FTP aclmanagerprotocache_object acllocalhostsrc /32::1 aclto_localhostdst / /32::1

8 aclbdxsrc /24fd00:dead:beef::/64 aclprisrc /24fd00:dead:beef:2::/64 aclserveurssrc /24fd00:dead:beef:1::/64 aclssl_portsport443 aclconnectmethodconnect http_accessallowmanagerlocalhost http_accessdenymanager http_accessdeny!safe_ports http_accessdenyconnect!ssl_ports http_accessallowlocalhost http_accessallowbdx http_accessallowpri http_accessallowserveurs http_accessdenyall http_port3128 hierarchy_stoplistcgi-bin? coredump_dir/var/spool/squid3 refresh_pattern^ftp: % refresh_pattern^gopher: % 1440 refresh_pattern-i(/cgi-bin/ \?) 0 0% 0 refresh_pattern. 0 20% 4320 netfilter sera utilisé sur les routeurs afin d autoriser le trafic vers le port 3128 à destination du proxy, mais pas le trafic du port 80, 21 ou 443 (exemple de configuration) iptables-aforward-mstate--stateestablished,related-jaccept iptables-aforward-ptcp--dport3128-d jaccept iptables-aforward-ptcp--dport80-s jaccept iptables-aforward-ptcp--dport443-s jaccept iptables-aforward-ptcp--dport20-s jaccept iptables-aforward-ptcp--dport21-s jaccept iptables-aforward-jdrop Un accès Intranet et Internet à une solution de messagerie et à un CRM

9 Dans ce point ci, plusieurs notions nouvelles entrent en jeu : en effet, l entreprise doit être accessible de l extérieur. Bien évidemment, cela amène des questions relatives à la sécurité. A cet effet, sera mise en place une zone démilitarisée (DMZ) au sein du Système d Information, ce afin de garantir au mieux la sécurité de ce Système d Information. Cette DMZ sera située sur le site de Bordeaux, étant donné le rapport d employés présents directement sur le site. Les employés de Paris y accéderont via le VPN mis en place. Cette zone démilitarisée comprendra donc : un serveur WEB un serveur de mail le serveur de VoIP Elle sera protégée par un pare feu. Ceux ci seront de simples machines Linux, et le pare feu sera Netfilter. Le serveur DNS Celui ci répondra sur le port 53, uniquement à des requêtes DNS. Cette machine sera de type Linux, avec bind9 en tant que serveur DNS. Il sera intégré au serveur samba pour la simplicité de la configuration. Celui ci gèrera aussi bien les résolutions locales (projetreseau.local) que les résolutions depuis Internet (projetreseau.com) : cependant, cette fonctionnalité ne pourra pas être testée, étant donné la variabilité de l adresse IP publique utilisé par la machine de virtualisation, la non possibilité de configurer le NAT de VMWare, ainsi que la non mise à disposition d un nom de domaine le permettant. Sa mise en place ne sera pas réalisée. Elle sera cependant simple. Il faudra configurer le NAT entrant pour autoriser les requêtes DNS et les rediriger vers le serveur DNS interne (table mangle d iptables) Le serveur web Le serveur web, quant à lui, ne répondra que sur le port 80, à la fois aux clients internes à l entreprise qu aux clients externes. Il accueillera le CRM de l entreprise, qui disposera lui d une authentification via l Active Directory de l entreprise. Il devra donc pouvoir interroger l annuaire de l entreprise. Le fichier de configuration d Apache n a pas été modifié par rapport à la version par défaut Fichier de configuration de l hôte virtuel sugar.projetreseau.local : 001-sugar

10 <VirtualHost*:80> ServerNamesugar.projetreseau.local DocumentRoot/var/www/sugar ErrorLog/var/log/apache2/sugar-error.log </VirtualHost> Le serveur mail Les collaborateurs doivent pouvoir envoyer et recevoir des mails, au sein de l entreprise mais également vers l extérieur. Celui ci accueillera donc les connexions sur le port 25 (SMTP) depuis le réseau local et l extérieur, et écoutera pour la récupération des messages sur le ports 993 (IMAPS) Il accueille une interface de type webmail, intégrée à la solution choisie, Zimbra. Le serveur de VoIP Le serveur de VoIP doit permettre autant des appels internes que des appels externes. A cet effet, il sera joignable depuis l intérieur et l extérieur de l entreprise Accessibilité de l extérieur Afin de rendre accessible ces services de l extérieur, il aurait fallu créer des règles de NAT/PAT sur les différents pare feux, afin de rediriger correctement ces flux vers les bons serveurs internes. Malheureusement, du fait du manque de temps cela n a pas pu être effectué. Les règles de NAT utiliseraient la table mangle afin de modifier les paquets et les diriger vers la bonne destination. Une connectivité IPv6 L auto configuration du protocole IPv6 sera utilisée, via le démon radvd qui sera installé sur les interfaces internes des routeurs/pare feux. Celui ci diffusera son préfixe, et les clients génèreront eux mêmes une adresse IPv6. L IPv6 ayant précédance lorsqu elle cohabite avec la version 4 sur un réseau, celle ci sera naturellement utilisée lorsque disponible. Par simplicité, une connectivité IPv4 sera tout de même assurée afin d éviter la mise en place d une passerelle 6to4 en sortie. La configuration DNS spécifiera les champs AAAA aux côtés des champs A classiques.

11 De la VoIP avec un standard Une politique de QoS aurait dû être appliquée afin de permettre au minimum 10 communications simultanées d avoir lieu dans de bonnes conditions. L exemple de mise en place de QoS afin de limiter le lien à 2mbps devrait être répliqué, en marquant les paquets des ports utilisés par la VoIP, et en les priorisant face au reste du trafic. Un IPBX sera configuré afin de faire office de standard. Un appel est possible entre Paris et Bordeaux, au travers du tunnel IPSec. L appel vers et depuis l extérieur n a pas été géré. De la supervision Afin de pouvoir détecter une panne sur le réseau, une solution de type Nagios sera mise en place, car sa réputation n est plus à faire dans ce domaine, et qu il est open source. Un serveur de type FAN (Fully Automated Nagios) a été installé, mais je n ai pas eu le temps de le configurer. Il ne monitore donc aucun service. Schéma de fonctionnement de l architecture III Plan d adressage 1) 3 sous réseaux

12 A) Sous réseau Paris /24 fd00:dead:beef:2::/64 B) Sous réseau DMZ Bordeaux /24 fd00:dead:beef:1::/64 C) Sous réseau Bordeaux /24 fd00:dead:beef::/64 Je reste bien évidemment à votre disposition pour toute information complémentaire par mail à l adresse oraulin@epsi.fr