Le document traite de l'installation d'une DMZ à trois niveaux pour sécuriser un réseau d'entreprise. Il décrit la configuration des pare-feux, des switches et des routeurs, ainsi que la composition des différentes DMZ et des services associés comme les serveurs de base de données, de mailing et de fichiers. Enfin, il aborde la mise en place de SSL sur les serveurs web pour garantir des connexions sécurisées.

1. INSTALLATION D’UNE
DMZ À 3 NIVEAUX
De nos jours, la sécurisation réseau demande de plus en plus
d’implication, c’est pourquoi la DMZ à plusieurs niveaux est un must-have
de tout système d’information qui se respecte.
Société GSB

2. I. Table des matières
II. Présentation sommaire du réseau.................................................................................................. 2
III. Mise en place des éléments d’interconnexion............................................................................ 3
A. Les pare-feux ............................................................................................................................... 3
1. Pare-feu interne ...................................................................................................................... 3
2. Pare-feu externe...................................................................................................................... 7
B. Les switches............................................................................................................................... 11
C. Les routeurs............................................................................................................................... 11
IV. Composition des DMZ interne & externe.................................................................................. 13
A. Serveur de Load Balancing ........................................................................................................ 13
B. Serveurs WEB ............................................................................................................................ 14
V. Composition de la DMZ « centrale »............................................................................................. 15
A. Serveurs de base de données en haute-disponibilité ............................................................... 15
1. Paramétrage de Heartbeat.................................................................................................... 15
2. Paramétrage de DRBD........................................................................................................... 16
B. Serveur de mailing..................................................................................................................... 18
C. Serveur de fichiers..................................................................................................................... 19
VI. Mise en place du SSL over http sur les serveurs Web............................................................... 20
A. Déploiement du fichier « hosts » .............................................................................................. 20
B. Création des certificats.............................................................................................................. 21
C. Import et installation du certificat ............................................................................................ 21

3. II. Présentation sommaire du réseau
Le réseau que j’ai mis en place pour le projet de fusion des sociétés Galaxy-Swiss et Bourdin se
présente ainsi. J’ai, au sein de mon LAN plusieurs VLAN qui comportent mes serveurs, les différents
sous-réseaux suivant les départements de l’entreprise et un VLAN de management.
J’ai également une DMZ qui se voit découper en trois niveaux distincts : il y a la DMZ à proprement
parler, celle se trouvant entre mes deux pare-feux. Celle-ci est composée de mes deux serveurs de
base de données en RAID1 et supervisé par HEARTBEAT concernant leur haute-disponibilité, un
serveur de mailing permettant pour le moment à mes utilisateurs de communiquer en interne, ainsi
qu’un serveur de fichiers SAMBA dans le cas où chaque département aurait besoin d’y placer des
fichiers pour les partager soit avec d’autres services de l’entreprise, soit avec des prestataires
externes.
Ensuite vient ce que j’appelle la DMZ interne, comportant un serveur de LoadBalancing et deux
serveurs Web permettant de nourrir la base de données en DMZ. Ces serveurs sont accessibles par
les employés de GSB.
Le dernier groupe de cette DMZ est le pendant externe de ma DMZ interne. En effet, les utilisateurs
qui ne font pas partie de l’entreprise GSB pourront venir travailler sur cette base de données
également via cette DMZ.

4. III. Mise en place des éléments d’interconnexion
A. Les pare-feux
Les deux pare-feux permettant la mise en place de cette DMZ à 3 niveaux sont deux pare-feux
pfSense.
1. Pare-feu interne
Le premier pare-feu est le pare-feu « interne ». Il est celui qui filtrera le plus possible de paquets pour
garder mon LAN dans des conditions de sécurité optimales.
a) Différentes interfaces
Ce pare-feu est composé de 3 interfaces (LAN, WAN et OPT1).
➢ Interface LAN :
IP : 172.18.0.2
MASK : 255.255.255.0
GATEWAY : 172.18.0.1 (VERS IP VIRTUELLE VRRP R_LAN & R_LAN2)
➢ Interface WAN :
IP : 172.21.1.1
MASK : 255.255.255.0
GATEWAYS : 172.21.1.254 / 172.21.1.253 (MANAGEMENT SWITCH)
➢ Interface OPT1 :
IP : 172.19.1.254
MASK : 255.255.255.0
GATEWAY : 172.19.1.253 (MANAGEMENT SWITCH)

5. b) Routage
Les routes qui le composent permettent à chaque élément de communiquer avec le reste du réseau
étendu (LAN, DMZ, MANAGEMENT, OPENVPN, IPSEC).
c) Règles IP
(1) Interface LAN
Sur l’interface LAN je permets à chaque sous-réseau du LAN de communiquer de n’importe quelle
façon avec l’extérieur, ce qui permet une certaine flexibilité dans les connexions de mes utilisateurs.
De plus, utilisant le proxy transparent LightSquid, des règles explicites sont mentionnées pour que
chaque administrateur, même nouveau puisse connaître l’existence de cette technologie au sein de
notre système d’information.
Enfin, la règle de NAT me permettant de rediriger les demandes de connexions sur les ports
http/https du pare-feu sur le serveur de LoadBalancing.

6. (2) Interface WAN
L’interface WAN est certainement celle qui le montre le niveau de sécurité le plus élevé de mon
système d’information.
En effet sur cette interface, chaque autorisation est affectée aux IP des machines et non pas à des
réseaux. Il n’y a que les deux réseaux VPN qui bénéficient d’un tel traitement.
De plus chaque machine n’est autorisée que pour certains protocoles, en l’occurrence le NTP, le
SYSLOG et les requêtes DNS.

7. (3) Interface OPT1
Cette interface comporte aussi des règles très contraignantes ne permettant que l’utilisation de
certains protocoles envers un nombre très restreint de machines. Je ne leur donne que les droits
http/https/ftp vers l’extérieur pour permettre aux serveurs Linux de se mettre à jour et de
télécharger des paquets ou des logiciels via APTITUDE ou WGET.
On remarque aussi l’utilisation du port 3306 qui s’avère être le port utilisé par la base de données
MYSQL.

8. 2. Pare-feu externe
a) Différentes interfaces
Ce pare-feu est composé de 3 interfaces (LAN, WAN et OPT1).
➢ Interface LAN :
IP : 172.21.1.254
MASK : 255.255.255.0
GATEWAYS : 172.21.1.1
➢ Interface WAN :

9. IP : 50.0.0.0
MASK : 255.255.255.0
GATEWAY : 50.0.0.2
➢ Interface OPT1 :
IP : 172.20.1.254
MASK : 255.255.255.0
GATEWAY : 172.20.1.253 (MANAGEMENT SWITCH)
b) Routage
Les tables de routage de ce pare-feu sont moins fournies que celle du pare-feu interne car il n’y a pas
besoin d’entrer dans les tables de routage celles menant aux PC connectés via OpenVPN ou au site B
connecté par le tunnel IPSec.
c) Règles IP
(1) Interface LAN
Chaque paquet provenant du pare-feu interne arrive par le NAT et l’adresse IP source est donc celle
du WAN du pare-feu interne. Une seule règle est donc nécessaire pour permettre à tous les paquets
de sortir.

10. (2) Interface WAN
Sur l’interface WAN sont présentes les règles permettant la redirection de ports vers le serveur
LoadBalancing présent dans la DMZ externe, et permettent aux clients OpenVPN de venir s’identifier
pour accéder au réseau interne.
(3) Interface OPT1
Les règles ici sont assez strictes et ne permettent, à l’instar de la DMZ interne que peu de
connections, si ce n’est celle permettant d’accéder à Internet pour mettre à jour les machines et
télécharger des paquets.

11. (4) Interface IPsec
Sur cette interface j’autorise les deux réseaux provenant du site B (LAN et LAN management) à
communiquer avec mes réseaux serveurs & DMZ.
(5) Interface OpenVPN

12. Sur cette interface j’autorise les machines connectées via le VPN à accéder aux réseaux serveurs &
DMZ.
B. Les switches
Les switches présents sont tous supervisés via SYSLOG, via un VLAN de management.
Leurs IP respectives sont 172.28.1.9 (Sw_DMZ), 172.30.1.12 (Sw_Web1) et 172.31.1.13 (Sw_Web2).
C. Les routeurs
Les routeurs limitrophes menant à la DMZ sont Routeur_NAT et R_LAN/R_LAN2 qui bénéficient du
système VRRP par l’IP virtuelle 172.18.0.1
Extrait de la configuration de R_LAN :

14. IV. Composition des DMZ interne & externe
A. Serveur de Load Balancing
Le serveur de Load Balancing permet à toutes les requêtes concernant les ports 80/443 d’être
réparties sur deux serveurs Web prévus à cet effet.
La configuration de ce serveur se trouve dans le fichier de configuration :
Une fois qu’un client se connecte sur un des deux serveurs Web, un cookie s’installe sur la machine,
ce qui implique que toutes les connexions futures se feront également sur ce serveur Web en
particulier.
Exemple d’un fichier de cookie à l’inspection d’un navigateur :

15. B. Serveurs WEB
Les deux serveurs Web sont disponibles pour pouvoir répartir correctement la charge entre toutes
les machines. Leurs configurations sont très similaires, en voici un exemple sur le premier des deux
serveurs :

16. V. Composition de la DMZ « centrale »
A. Serveurs de base de données en haute-disponibilité
Pour préparer le bon fonctionnement des deux serveurs de bases de données, nous devons au
préalable renseigner le fichier « hosts » avec ces données :
1. Paramétrage de Heartbeat
Les deux serveurs accueillant les bases de données bénéficient d’un RAID 1 et d’une haute-
disponibilité via une IP virtuelle attribuée par le logiciel Heartbeat.
Ce système permet, à la chute d’un des deux serveurs, ou le dysfonctionnement d’un des disques
durs, de ne perdre aucune donnée et de pouvoir par la suite les rétablir sur une autre machine.

17. La configuration de Heartbeat se trouve dans des fichiers de configuration présent sur les deux
serveurs.
Voici, à titre d’exemple, ceux présents sur la première base de données :
Une fois ces configurations mises en place, le serveur étant sélectionné en tant que serveur
« primary » se verra attribuée l’adresse IP virtuelle.
2. Paramétrage de DRBD
DRBD nous servira à configurer un RAID1 entre les deux serveurs de bases de données, ce qui
assurera une réplication entre ces deux machines et nous permettra de ne perdre aucune donnée en
cas de crash d’une des deux machines.
Le fichier de configuration se nomme drbd.res et se trouve dans le dossier concernant drbd.

18. Une fois ces paramètres renseignés, nous pouvons alors synchroniser les deux serveurs ensemble, ce
qui permettra de mettre en place la Haute-disponibilité.
Quand la synchronisation sera terminée, la partition virtuelle drbd0 apparaîtra sur la machine
primaire. Voici comme exemple le serveur database2 :

19. B. Serveur de mailing
La DMZ comporte aussi un serveur de mail. Ce dernier permet pour le moment aux utilisateurs du
domaine de communiquer entre eux.
J’ai choisi comme technologie PostFix (SMTP), Dovecot (IMAP/POP3) et RainLoop (consultation des
mails).
Postfix dispose d’une console d’administration où l’ont peut y renseigner des domaines de
messageries, des utilisateurs, etc…
En ce qui concerne la consultation des mails on utilise le client RainLoop comme ci-dessous :

20. C. Serveur de fichiers
Comme serveur de fichiers, j’ai décidé d’utiliser SAMBA sur un serveur LINUX.
J’ai créé un partage, accessible par un utilisateur nommé neoflow, n’ayant pas eu réellement le
besoin d’utiliser un serveur de fichiers.

21. VI. Mise en place du SSL over http sur les serveurs Web
Pour pouvoir autoriser les machines à communiquer en HTTPS sur les serveurs Web des DMZ interne
& externe, j’ai choisi d’y ajouter un certificat signé par une AC elle aussi présente sur le serveur.
A. Déploiement du fichier « hosts »
Pour chaque machine Windows, je déploie un fichier hosts via une GPO avec comme résolution de
noms les machines composant la DMZ, leur extension étant « .gsb.dmz » et non pas
« galaxy.swiss.local ».
Le contenu du fichier hosts est le suivant :
La ligne de commande s’exécutant dans la GPO est la suivante :
Je lance ensuite ce script au démarrage de mes machines sur l’OU correspondantes aux PC
Windows :

22. B. Création des certificats
Pour pouvoir assurer une connexion sécurisée, j’ai créé via OpenSSL un certificat d’AC et un certificat
serveur signé par ce dernier.
Les fichiers sont les suivants :
• le fichier « ca.crt » correspond au certificat de l’Autorité de Certification
• le fichier « ca.key » correspond à la clé privée de l’Autorité de Certification
• le fichier « ca.srl » contient un identifiant qui sera incrémenté pour une nouvelle demande
de signature
• le fichier « certifapache.crt » correspond au certificat auto-signé de votre serveur Apache
• le fichier « cleprivapache.key » correspond à la clé privée de votre serveur Apache
• le fichier « demandesignature.csr » correspond à la demande à faire signer par l’Autorité de
Certification
C. Import et installation du certificat
J’ai choisi d’utiliser WinSCP pour transférer le certificat depuis le serveur sur le serveur Active
Directory :

23. Puis je déploie le certificat par GPO pour chaque utilisateur du domaine :
Lors de la prochaine connexion au serveur Web, l’utilisateur aura alors la certitude d’être sur une
connexion https sécurisée.