Simulation d`un réseau d`entreprise

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 :
http://www.dailymotion.com/video/k6jZHE5iO9UDrP3MjuX
http://www.dailymotion.com/video/k3ipU6qCRvM8VP3Mjvn
http://www.dailymotion.com/video/k3b7OYw30PF9Mp3MjHO
http://www.dailymotion.com/video/k7i8CptfR6JIss3Mknr
http://www.dailymotion.com/video/k5CDPMMg1Vsv6i3MkAR
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 - Openswan IPsec configuration file
# This file: /usr/share/doc/openswan/ipsec.conf-sample
#
# Manual:
ipsec.conf.5
version
2.0
# conforms to second version of ipsec.conf specification
# basic configuration
config setup
nat_traversal=yes
# exclude networks used on server side by adding %v4:!a.b.c.0/24
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.0.0/24
,%v6:fc00::/7
# OE is now off by default. Uncomment and change to on, to enable.
oe=off
# which IPsec stack to use. auto will try netkey, then klips then mast
protostack=netkey
interfaces=%"defaultroute"
# Add connections here
conn projetreseau
type=tunnel
authby=secret
left=192.168.3.1
right=192.168.3.2
leftsubnets={192.168.0.0/24 192.168.1.0/24}
rightsubnet=192.168.2.0/24
auto=start
conn projetreseauv6
connaddrfamily=ipv6
tu
a
yt
ph
eb
=y
t=
us
ne
nc
er
let
left=fd00:dead:beef:3::1
right=fd00:dead:beef:3::2
leftsubnets={fd00:dead:beef:1::/64 fd00:dead:beef::/64}
rightsubnet=fd00:dead:beef:2::/64
auto=start
/etc/ipsec.secrets
include /var/lib/openswan/ipsec.secrets.inc
192.168.3.1 192.168.3.2 : PSK
"0xe6cf42f0_84f90d68_587a782f_913306f8_43b2b779_6201fe50_107621a5_2d9024f8"
fd00:dead:beef:3::1 fd00:dead:beef:3::2 : PSK "SECRET"
Pour la QoS, la commande Linux tc sera utilisée
tc qdisc add dev eth1 root handle 1: htb default 1 r2q 160
tc class add dev eth1 parent 1: classid 1:1 htb rate 2048kbit
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).
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
# Global parameters
[global]
workgroup = PROJETRESEAU
realm = PROJETRESEAU.LOCAL
netbios name = SAMBA
server role = active directory domain controller
[netlogon]
path = /usr/local/samba/var/locks/sysvol/projetreseau.local/scripts
read only = No
[sysvol]
path = /usr/local/samba/var/locks/sysvol
read only = No
[test]
path=/share/test
read only = No
public = yes
krb5.conf
[libdefaults]
default_realm = PROJETRESEAU.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = true
projetreseau.local.zone
$ORIGIN projetreseau.local.
$TTL 1W
@
IN SOA samba
hostmaster (
2013010317 ; serial
2D
; refresh
4H
; retry
6W
1W )
IN NS samba
IN AAAA
fd00:dead:beef::1
IN A
192.168.0.1
;
@
mail
IN
IN
MX
MX
10
10
; expiry
; minimum
mail
mail
samba
IN AAAA
fd00:dead:beef::1
samba
IN A
192.168.0.1
gc._msdcs
IN A
192.168.0.1
gc._msdcs
IN AAAA
fd00:dead:beef::1
06a7f8ee-59c4-4445-b075-10a818fc2ccc._msdcs
IN CNAME
samba
;
; global catalog servers
_gc._tcp
IN SRV 0 100 3268 samba
_gc._tcp.Default-First-Site-Name._sites IN SRV 0 100 3268 samba
_ldap._tcp.gc._msdcsIN SRV 0 100 3268 samba
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs IN SRV 0 100 3268 samba
;
; ldap servers
_ldap._tcp
IN SRV 0 100 389
samba
_ldap._tcp.dc._msdcsIN SRV 0 100 389
samba
_ldap._tcp.pdc._msdcs
IN SRV 0 100 389
samba
_ldap._tcp.45f4bae5-0589-441d-9406-725577719f8e.domains._msdcs
IN SRV
100 389 samba
_ldap._tcp.Default-First-Site-Name._sites
IN SRV 0 100 389 samba
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs IN SRV 0 100 389 samba
;
; krb5 servers
_kerberos._tcp
IN SRV 0 100 88
samba
_kerberos._tcp.dc._msdcs IN SRV 0 100 88
samba
_kerberos._tcp.Default-First-Site-Name._sites IN SRV 0 100 88
samba
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
IN SRV 0 100 88 samba
_kerberos._udp
IN SRV 0 100 88
samba
; MIT kpasswd likes to lookup this name on password change
_kerberos-master._tcp
IN SRV 0 100 88
samba
_kerberos-master._udp
IN SRV 0 100 88
samba
;
; kpasswd
_kpasswd._tcp
IN SRV 0 100 464
samba
_kpasswd._udp
IN SRV 0 100 464
samba
;
; heimdal 'find realm for host' hack
_kerberos
IN TXTPROJETRESEAU.LOCAL
0
proxy IN
proxy IN
A
AAAA
192.168.1.10
fd00:dead:beef:1::10
mail
mail
IN
IN
A
AAAA
192.168.1.11
fd00:dead:beef:1::11
voip
voip
IN
IN
A
AAAA
192.168.1.12
fd00:dead:beef:1::12
web
web
IN
IN
A
AAAA
192.168.1.13
fd00:dead:beef:1::13
samba IN
samba IN
A
AAAA
192.168.0.1
fd00:dead:beef:0::1
samba-pri IN A
samba-pri IN AAAA
192.168.2.2
fd00:dead:beef:2::2
gw-bdx
gw-bdx
IN
IN
A
AAAA
192.168.1.254
fd00:dead:beef:1::ffff
samba-pri
samba-pri
IN
IN
A
AAAA
102.168.2.1
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.
(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
acl Safe_Ports port 80
acl Safe_Ports port 443
acl Safe_Ports port 21
#HTTP
#HTTPS
#FTP
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
acl bdx src 192.168.0.0/24 fd00:dead:beef::/64
acl pri src 192.168.2.0/24 fd00:dead:beef:2::/64
acl serveurs src 192.168.1.0/24 fd00:dead:beef:1::/64
acl SSL_ports port 443
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access allow bdx
http_access allow pri
http_access allow serveurs
http_access deny all
http_port 3128
hierarchy_stoplist cgi-bin ?
coredump_dir /var/spool/squid3
refresh_pattern ^ftp:
1440
refresh_pattern ^gopher: 1440 0%
refresh_pattern -i (/cgi-bin/|\?) 0
refresh_pattern .
0
20%
20%
1440
0%
4320
10080
0
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 -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp --dport 3128 -d 192.168.1.10 -j ACCEPT
iptables -A FORWARD -p tcp --dport 80 -s 192.168.1.10 -j ACCEPT
iptables -A FORWARD -p tcp --dport 443 -s 192.168.1.10 -j ACCEPT
iptables -A FORWARD -p tcp --dport 20 -s 192.168.1.10 -j ACCEPT
iptables -A FORWARD -p tcp --dport 21 -s 192.168.1.10 -j ACCEPT
iptables -A FORWARD -j DROP
Un accès Intranet et Internet à une solution de messagerie et à un
CRM
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
<VirtualHost *:80>
ServerName sugar.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.
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
A) Sous­réseau Paris
192.168.2.0/24
fd00:dead:beef:2::/64
B) Sous­réseau DMZ Bordeaux
192.168.1.0/24
fd00:dead:beef:1::/64
C) Sous­réseau Bordeaux
192.168.0.0/24
fd00:dead:beef::/64
Je reste bien évidemment à votre disposition pour toute information complémentaire par mail à
l’adresse [email protected]