INFRASTRUCTURE D’HEBERGEMENT WEB A HAUTE DISPONIBILITE Dossier Technique : Projet Professionnel Encadré

SEVAT Arthur CFA ECR: BTS SIO Option SISR

Page 2 of 38

Sommaire 1) Contexte ……………………………………………………………………………………………………………………………. 1.1) Présentation de l’entreprise 1.1.1) Objectifs 1.1.2) Enjeux 1.1.3) Contraintes 1.1.4) Besoins - Spécifications 1.2) Site E-commerce 1.2.1) CMS 1.2.2) Les CMS E-commerce 1.2.3) Choix du CMS 2) Infrastructure Réseau ………………………………………………………………………………………………………… 2.1) Virtualisation 2.1.1) Logiciels de Virtualisation 2.1.2) Choix du logiciel de Virtualisation 2.1.3) Système d’Exploitation 2.1.3.1) Systèmes d’exploitation existants 2.1.3.2) Choix du Système d’Exploitation 2.2) Serveur Web 2.2.1) Comparaison Apache / Nginx 2.2.2) Choix du Serveur Web 2.2.3) LoadBalancing 2.3) Serveur SGBD 2.3.1) Quelques SGBD 2.3.2) Choix du Serveur SGBD 2.3.3) Réplication de bases de données 2.4) Serveur de Sauvegarde 2.4.1) Différentes méthodes de Sauvegarde 2.4.2) Choix de la méthode de Sauvegarde 2.5) Serveur SSH 2.5.1) SSH 2.5.2) TeraTerm 2.6) Récapitulatif 3) Installation via VirtualBox ………………………………………………………………………………………………… 3.1) Installation des machines virtuelles - Debian 9 Stretch 64 bits 3.1.1) Mise à jour des paquets 3.1.2) Configuration des IP statiques 3.1.3) Installation du serveur SSH 3.2) Installation Serveur Web 1 & 2 (Apache) 3.3) Installation et configuration Serveur SGBD 3.3.1) Installation d’une interface graphique – PhpMyAdmin 3.3.1) Mis en place d’une réplication de base de données 3.4) Créer une solution de sauvegarde 3.4.1) Script générant un fichier de sauvegarde de la base de données 3.4.2) Automatisation de l’exécution du Script – Crontab 3.4.3) Envoi du fichier vers le Serveur de Sauvegarde 3.5) Installation de PrestaShop 3.5.1) Installation 3.5.2) Mise en place de la réplication via Lsyncd 3.6) Installation de Zevenet 3.6.1) Installation 3.6.2) Configuration

Pages 4-7 Pages 8-14 Pages 15-25

Page 3 of 38

4) Sécurisation du réseau via ACL …………………………………………………………………………………………… 4.1) Fiche matériel 4.2) Configuration 5) Tests de fonctionnement de l’Infrastructure Réseau …………………………………………………………..

5.1) Accessibilité du site en local (Serveur Web 1 & 2) 5.2) Accessibilité du site en local (Serveur Proxy – LoadBalancing) 5.3) Réplication de la base de données 5.4) Réception du fichier de sauvegarde

6) Conclusion …………………………………………………………………………………………………………………………. Annexes ………………………………………………………………………………………………………………………………….

Pages 26-27 Pages 27-29 Pages 29 Pages 30-38

Page 4 of 38

1) Contexte Une TPE nommée IW s’est récemment lancé dans l’E-Commerce. Offrant des produits reconditionnés à bas prix, son chiffre d’affaire a rapidement augmenté ainsi que sa réputation. Devenu rapidement un site référence en France dans le domaine du reconditionné, IW devient la cible de cyber attaques. Récemment IW a vu sa base de données de produits altérée par une influence extérieure. Cela peut s’expliquer par le peu de protection que IW a mis en place dans son infrastructure réseau. L’entreprise a aussi observé de larges pics de connexion à certaines heures de pointes sur Internet. Leur site d’E-commerce est tombé plusieurs fois suite à ces pics. Ce manque de haute disponibilité impacte directement et de manière négative le chiffre d’affaire et la crédibilité de IW. Cherchant un moyen de sécuriser son système d’hébergement face à ces intrusions ainsi que de développer sa haute disponibilité, la TPE a fait appel un appel d’offre afin de déterminer les besoins de l’entreprise et de trouver une solution adaptée à leurs besoins.

1.1) Présentation de l’entreprise 1.1.1) Objectifs IW cherche à devenir un des leaders de l’e-commerce de produit technologiques reconditionnés. Il va nous falloir adapter son infrastructure d’hébergement Web à son activité ainsi qu’à la densité des flux auxquels elle sera exposée.

• Transformer son infrastructure Web afin d’éviter les SPOF (single point of Failure). • Mettre en place une solution de sauvegarde afin de garder une base de données saine. • L’infrastructure doit être modulable afin d’avoir des performances adaptables à de

potentielles mise à jour et/ou upgrade.

1.1.2) Enjeux IW a déjà observé des intrusions dans leurs systèmes ainsi que dans leur base de données. Les temps d’arrêt de leur service leur a valu une baisse de leur chiffre d’affaires.

• Le manque de sécurité met à mal la fiabilité de IW à stocker des informations clients. • Il faut limiter les accès au strict minimum afin de ne pas laisser de backdoor potentielle. • Si les temps d’arrêt continuent, IW perdra en crédibilité et en chiffre d’affaires.

1.1.3) Contraintes IW a fait des investissements au lancement de l’entreprise. Leur fond d’investissement est déjà épuisé sur d’autres projets. Nous devons donc leur trouver une solution le moins cher possible afin qu’ils puissent répondre à leurs objectifs tout en restant dans leurs moyens.

• Moyens limités tant hardware que software. • Le matériel doit pouvoir être maintenu par le personnel de IW après rendu du projet.

1.1.4) Besoins - Spécifications

L’entreprise possède déjà un lot de matériel disponible, tel qu’un Routeur (4. Sécurisation via ACL) et un serveur supplémentaire qui nous permettra de mettre en place nos solutions.

• Le serveur doit supporter l’outil Virtual Box et doit être équipé de plusieurs cartes réseaux afin de mettre en place notre solution de sécurité.

Page 5 of 38

Définition du problème Intrusion externe : IW a observé des accès non désirés sur sa base de données.

Temps d’arrêt du site d’E-Commerce : Le site IW est victime de son succès et possède de nombreux SPOF (single point of Failure)

Influence du problème Importante : L’entreprise se doit de protéger les données de ses clients pour des raisons législatives et de réputation.

Importante : La crédibilité de l’entreprise à fournir un service est amoindri par la quantité de temps d’arrêts de leur serveur.

Objectif du projet Sécuriser l’accès à la base de données afin de bloquer les connexions en provenance de l’extérieure. Étendre cette protection sur l’ensemble de l’infrastructure de IW.

Augmenter les capacités d’accueil du site de E-Commerce de IW afin de pouvoir supporter l’afflux aux heures de pointes. Trouver une solution aux problèmes de SPOF de IW.

Description des besoins Le rajout de filtres pour limiter et contrôler les connexions peut permettre de résoudre le problème de connexions non désirées. Créer un couloir sécurisé dirigeant les clients vers le site de E-Commerce est une solution viable

Afin de limiter les SPOF, l’infrastructure actuelle doit évoluer et accueillir des moyens de déduplication de ses services : . Réplication de base de données . Sites Web en parallèle . Loadbalancing (Répartition des charges) . Cluster & Farm (Blocs de services)

Enveloppe Budgétaire IW ne possède pas encore les moyens d’investir dans des solutions hautes gammes et onéreuses. L’enveloppe n’est donc pas suffisante pour investir dans des Softwares onéreux ou dans des serveurs dédiés professionnels.

Délais Un délai de 2 mois a été choisi afin de chercher et développer la solution à leurs problèmes. 3 mois supplémentaires sont accordés pour mettre en œuvre cette solution.

Page 6 of 38

Page 7 of 38

1.2) Site E-commerce 1.2.1) CMS

Les CMS ou Content Management System (système de gestion de contenu en français) est une famille de logiciels destinée à la conception et à la mise à jour dynamique de sites Web ou d'applications multimédia. Dans le cas présent, nous nous intéressons précisément au CMS spécialisés dans la création et la gestion de sites d’E-commerce.

1.2.2) Les CMS E-commerce

Wordpress Odoo Shopify Prestashop Version Mobile

Oui Oui Oui Oui

Newsletters Plugin Oui Oui Plugin Ajout de code Oui Oui Oui Oui Modèle éco Gratuit Gratuit/Payant Payant Gratuit Commissions Non Non 0.5% à 2% Non Support Communauté très

active (forums et blogs), support variable en fonction des éditeurs de thèmes

Documentation & FAQ Forums

Téléphone, chat, email (en anglais), documentation, forum

Documentation & FAQ Assistance technique personnalisée payante

1.2.3) Choix du CMS

Les développeurs de IW nous ont fait part de leur avis et de leur expérience avec les CMS. Limité par les choix gratuits, ils ont demandé l’implémentation de Prestashop dans notre solution Ce dernier répond aux exigences techniques demandées et est compatible avec les solutions que nous allons proposer.

Page 8 of 38

2) Infrastructure Réseau

2.1) Virtualisation 2.1.1) Logiciels de Virtualisation

Les logiciels de virtualisation permettent la virtualisation d’un ou plusieurs systèmes d'exploitation (ou applications complexes) comme un simple logiciel, sur un (ou plusieurs) système d’exploitation fonctionnant sur ordinateur (ou serveur), au lieu de ne pouvoir en installer qu'un seul par machine. Ces ordinateurs virtuels sont appelés Virtual Environment ou VE. Les deux plus courant sont VirtualBox et VMWare.

VirtualBox VMWare workstation Pro Licence Open Source Propriétaire Prix Gratuit Gratuit / 274,95€ Snapshot support Oui Oui Interface graphique Oui Oui OS Hôte supporté(s) • Windows 7

• Windows 8 • Windows 8.1 • Windows 10 • Windows Server 2008 R2 • Windows Server 2012 • Windows Server 2016 • Windows Server 2019 • Mac OS X 10.12 • Mac OS X 10.13 • Mac OS X 10.14 • Ubuntu • Debian • Oracle Linux • Redhat Enterprise Linux • Fedora • Gentoo Linux • SUSE Linux Enterprise server • openSUSE Leap

• Ubuntu 15.04 and above • Red Hat Enterprise Linux 6 & above • CentOS 7.0 and above • Oracle Linux 7.0 and above • openSUSE Leap 42.2 and above • SUSE Linux 13 and above

OS Hébergé(s) supporté(s) • Windows 10 • Windows 8.X • Windows 7 • Windows XP • Ubuntu • Red Hat • SUSE • Oracle Linux • Debian • Fedora • openSUSE • Mint • CentOS • +

• Windows 10 • Windows 8.X • Windows 7 • Windows XP • Ubuntu • Red Hat • SUSE • Oracle Linux • Debian • Fedora • openSUSE • Mint • CentOS • +

Page 9 of 38

2.1.2) Choix du logiciel de Virtualisation

L’entreprise IW ayant déjà travaillé avec VirtualBox et vu la haute compatibilité du logiciel avec une grande variété d’OS Hôte, il est décidé que l’infrastructure d’hébergement sera hébergée via VirtualBox.

2.1.3) Système d’Exploitation 2.1.3.1) Systèmes d’exploitation existants Pour des raisons de respect de l’enveloppe budgétaire, la liste des systèmes d’exploitation pouvant être utilisés a été limitée à Debian et Ubuntu. Deux OS gratuits très performants. Ces OS ont aussi pour intérêts techniques d’être extrêmement compatible avec tout type de service pouvant être mis en place et fonctionnel en installation basique sans interface graphique.

2.1.3.2) Choix du Système d’Exploitation Après concertation avec les développeurs de l’entreprise IW, il est décidé d’utiliser l’OS Debian. Cela ressort d’une habitude d’utilisation de la part de la majorité du personnel de IW.

2.2) Serveur Web 2.2.1) Comparaison Apache / Nginx Apache et Nginx sont deux des plus courants systèmes de serveur HTTP/HTTPS. Les deux systèmes, dans leurs dernières versions, peuvent rivaliser l'un avec l'autre dans la plupart des domaines. Pour le contenu statique, NGINX performe bien au-delà des performances d’Apache, mais pour un contenu dynamique, la différence de performance est assez mince. NGINX brille avec certaines de ses fonctionnalités plus avancées (diffusion multimédia, reverse-proxy pour les protocoles non HTTP), ainsi que son soutien commercial et sa formation. Les propriétaires de sites Web à fort trafic qui doivent servir beaucoup de contenu statique et / ou de flux multimédia préféreront probablement NGINX (ou utiliseront une combinaison d'Apache et NGINX). Dans la plupart des autres cas d'utilisation de site Web, aussi bien Apache que Nginx feront le travail très bien

2.2.2) Choix du Serveur Web Pour des raisons de respect des contraintes, nous utiliserons Apache car le personnel de IW manque d’expérience avec le système de serveur NGINX. Le personnel étant plus expérimenté avec Apache, la solution sera plus rapidement développée et rapidement mise en place.

2.2.3) LoadBalancing Afin de répartir la charge sur les différents sites Web, nous allons utiliser une solution de LoadBalancing. Cette solution permet de multiplier les capacités d’accueil par le nombre de serveur Web ainsi que de rediriger les clients en cas d’arrêt d’un des serveurs Web.

2.3) Serveur SGBD 2.3.1) Quelques SGBD

Les SGBD ou Système de Gestion de Base de Données sont des logiciels permettant de stocker des informations dans une base de données. Ils permettent de lire, écrire, modifier et trier les informations stockées dans des bases de données.

Oracle DB PostgreSQL MySQL MongoDB Compatibilité Prestashop Non Non Oui Non Licence Propriétaire OpenSource OpenSource OpenSource Modèle économique Payant Gratuit Gratuit Gratuit Support Payant Gratuit / Payant Gratuit Gratuit

2.3.2) Choix du Serveur SGBD

Pour des raisons de compatibilité nous utiliserons MySQL. Le CMS Prestashop fonctionne avec des bases de données construites avec le SGBD MySQL.

Page 10 of 38

2.3.3) Réplication de bases de données

Afin d’appliquer la haute disponibilité aux bases de données, nous mettrons en place une réplication de bases de données. Cette réplication, configurée en Master-to-Master, permettra d’utiliser des miroirs du site web avec des bases de données identiques en continu mais indépendantes l’une de l’autre.

2.4) Serveur de Sauvegarde 2.4.1) Différentes méthodes de Sauvegarde

Il existe actuellement 3 méthodes de sauvegarde : La sauvegarde complète, différentielle et incrémentielle

2.4.2) Choix de la méthode de Sauvegarde

En prenant en considération la quantité de données possédée par IW et par respect des contraintes budgétaire, nous déploierons une solution de sauvegarde complète des bases de données sur un serveur Debian tiers. Nous procéderons à un dump des bases de données dans un fichier au format .sql avant de le synchroniser via rsync avec le serveur de sauvegarde. Ces tâches seront automatisées via Crontab.

2.5) Serveur SSH 2.5.1) SSH

Afin de procéder aux sauvegardes ainsi qu’à l’administration à distance de nos VM nous utiliserons le protocole SSH. Nous utiliserons l’installation standard et les clés publiques afin de ne pas à avoir utiliser les identifiants durant les tâches automatisées.

2.5.2) TeraTerm

Nous utiliserons le logiciel TeraTerm pour administrer nos VM via SSH. TeraTerm est un émulateur Open Source permettant d’émuler la console d’un terminal via SSH, Telnet ou autre.

Type de sauvegarde Complète Différentielle Incrémentielle Espace Requis ++++ +++ ++ (+++ en pratique) Restauration -1 sauvegarde complète -1 sauvegarde complète

-1 sauvegarde différentielle depuis la dernière complète

-1 sauvegarde complète -Toutes les sauvegardes incrémentielles depuis la dernière complète

Méthode Sauvegarde toutes les données.

Sauvegarde les modifications depuis la dernière sauvegarde complète.

Sauvegarde les modifications depuis la dernière sauvegarde incrémentielle. La première incrémentielle sauvegarde les modifications depuis la sauvegarde complète.

Page 11 of 38

2.6) Récapitulatif

Hardware Serveur de VM Routeur Spécifications - Processeur Intel Core i5 4570

- 24 Go de mémoire type DDR3 - Intel® HD Graphic 4600 - HDD 500 Go SATA III - Intel Corp Ethernet Connection I217-LM - 4x Realtek RTL8111/8168/8411 PCI-Ex Gbit

(Voir 4.1 : Fiche matériel)

Coût Mis à disposition par IW Mis à disposition par IW

Software Prestashop Zevenet MySQL Spécifications CMS d’e-commerce Loadbalancer SGDB Coût immédiat Gratuit Gratuit Gratuit Coût d’investissement Prix par module Devis au cas par cas Gratuit

Page 12 of 38

Page 13 of 38

Page 14 of 38

Page 15 of 38

3) Installation via VirtualBox Pour des raisons de sécurité, le dossier technique ne contient aucun mot de passe utilisé pour l’installation ou la configuration des VM. Afin de protéger les serveurs, aucune adresse IP ne sera divulguée.

3.1) Installation des machines virtuelles - Debian 9 Stretch 64 bits

Nous procédons à une installation standard des VM Debian 9 Stretch 64 bits sans interface graphique. (Voir annexes : 2.1.DEBIAN ; 2.2.DEBIAN)

3.1.1) Mise à jour des paquets

Afin de nous assurer que nous possédions les dernières mises à jour nous procéderons à l’utilisation des commandes :

>> apt update >> apt upgrade

3.1.2) Configuration des IP statiques

Nous allons assigner des adresses IP statiques à nos VM afin de fixer notre infrastructure. On pourra alors automatiser certaines tâches. La majorité de nos services (loadbalancing, DB en remote access, …) requiert des adresses IP statiques. Le ficher «interfaces» sera modifié de tel sorte :

>> nano /etc/network/interfaces 1. # This file describes the network interfaces available on your system 2. # and how to activate them. For more information, see interfaces(5). 3. 4. source /etc/network/interfaces.d/* 5. 6. # The loopback network interface 7. auto lo 10. iface lo inet loopback 11. 12. # The primary network interface 13. allow-hotplug enp0s3 14. iface enp0s3 inet static 15. address 192.168.X.X 16. netmask 255.255.255.0 17. gateway 192.168.1.254

(Voir annexe : 3.IP)

3.1.3) Installation du serveur SSH

Afin d’administrer les VM à distance ainsi que de bénéficier des avantages à utiliser un émulateur tel que TeraTerm ou Putty, nous allons installer SSH :

>> apt install ssh >> nano /etc/ssh/sshd_config

Et générer une clé privée et publique :

>> ssh-keygen (Voir annexes : 3.1.1.SSH ; 3.1.2.KEYGEN )

Une fois les clés générées sur chaque VM, nous allons envoyer les clés publiques nécessaires afin de créer les tunnels protégés que nous désirons (ex. Le tunnel de réplication pour Lsyncd entre les serveurs Web) Pour cela nous devons autoriser une première connexion entrante afin d’envoyer les clés.

Page 16 of 38

Nous allons procéder à la configuration de ssh sur les VM réceptrices afin d’autoriser les connexions externes via utilisateur :

>> nano /etc/ssh/sshd_config

1. # $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $ 2. […] 123. 124. Port 22 125. PermitRootLogin yes 126. AllowUsers root

(Voir annexe : 3.2.1.CONF)

Nous pouvons par la suite transmettre la clé publique à la cible :

>> ssh-copy-id root@192.168.X.X Nous pouvons désormais nous connecter à l’hôte via la commande :

>> ssh 192.168.X.X (Voir annexe: 3.2.2.COPY ; 3.2.3.CONNECT) Les clés SSH ainsi que les mots de passe Root seront transmis à l’administrateur réseau de IW. Il sera le seul apte à administrer à distance les différentes VM de l’infrastructure.

3.2) Installation Serveur Web 1 & 2 (Apache)

Afin de permettre l’affichage de nos sites web nous avons besoin d’installer des serveurs web. La solution retenue est Apache2 :

>> apt install apache2 libapache2-mod-php >> apt install apache2 php php-cli

On prévoit la compatibilité avec le SGDB retenu (MySQL) :

>> apt install php-mysql (Voir annexe : 3.3.APACHE )

3.3) Installation et configuration Serveur SGBD

Afin de séparer les bases de données de leur site Web assigné, nous optons pour des bases de données en remote access. Pour cela nous les installons sur des VM différentes. Nous prévoyons d’utiliser une interface graphique nous allons donc installer Apache2 et php sur les serveurs de bases de données. Nous installons certaines extensions de php nécessaires au CMS :

>> apt install php-curl php-gd php-mbstring php-mcrypt php-xml >> apt install mysql-server mysql-client

Nous pouvons nous connecter à la console mysql et assigner un mot de passe à l’utilisateur root :

>> mysql MariaDB[(none)]> SET PASSWORD FOR ‘root’@’localhost’ = PASSWORD(‘password’); MariaDB[(none)]> FLUSH PRIVILEGES;

Page 17 of 38

3.3.1) Installation d’une interface graphique – PhpMyAdmin (sur les deux serveurs)

Nous allons procéder à l’installation de l’interface graphique sur les deux serveurs afin de nous aider dans l’administration de nos bases de données :

>> apt install phpmyadmin (Voir annexes : 3.4.1.PMA ; 3.4.2.PMA ; 3.4.3.PMA)

Pour des raisons de sécurité, nous allons créer un superuser mysql propre à Phpmyadmin afin de ne pas utiliser root.

>> mysql MariaDB[(none)]> GRANT ALL ON *.* TO ‘superuser’@’localhost’ IDENTIFIED BY ‘password’ WITH GRANT OPTION; MariaDB[(none)]> FLUSH PRIVILEGES;

3.3.1) Mis en place d’une réplication de base de données

La réplication Master-to-Master sera mise en place via l’interface graphique de Phpmyadmin. Elle permettra que chaque serveur de base de données soit un miroir de l’autre :

Nous allons tout d’abord créer un utilisateur de réplication :

Nom d’hôte correspond à l’IP du serveur de base de données miroir à celui que l’on configure.

Page 18 of 38

Nous pouvons maintenant procéder à la configuration de la réplication elle-même :

Nous commençons par la configurer les serveurs en tant que maître :

Il nous faut rajouter les lignes suivantes (encadré vert) au fichier my.cnf afin de doter notre serveur d’un ID :

>> nano /etc/mysql/my.cnf 1. # The MariaDB configuration file 2. # 3. # The MariaDB/MySQL tools read configuration files in the following order: 4. # 1. "/etc/mysql/mariadb.cnf" (this file) to set global defaults, 5. # 2. "/etc/mysql/conf.d/*.cnf" to set global options. 6. # 3. "/etc/mysql/mariadb.conf.d/*.cnf" to set MariaDB-only options. 7. # 4. "~/.my.cnf" to set user-specific options. 8. # If the same option is defined multiple times, the last one will apply. 9. # 10. # This group is read both by the client and the server 11. # use it for options that affect everything 12. # 13. [client-server] 14. # Import all .cnf files from configuration directory 15. !includedir /etc/mysql/conf.d/ 16. !includedir /etc/mysql/mariadb.conf.d/ 17. 18. server-id=8509784 19. log_bin=mysql-bin 20. log_error=mysql-bin.err

>> service mysql restart

Page 19 of 38

Après avoir exécuté, le serveur est désormais configuré en tant que maître. Il nous faut maintenant nous connecter à l’interface Phpmyadmin du serveur esclave et le configurer en tant que tel :

Nous configurons l’esclave avec les ID de l’utilisateur de réplication créé sur le serveur maître. Le client correspond à l’adresse IP du serveur maître :

Après exécution, la relation Master-to-Slave est créé :

Il faut maintenant reproduire les étapes en inversant le serveur Master et le serveur Slave pour transformer la relation Master-to-Slave en Master-to-Master.

Page 20 of 38

3.4) Créer une solution de sauvegarde

Nous mettons en place un système de sauvegarde complète via scripts automatisés. Le serveur de sauvegarde utilise l’OS Debian 9.

3.4.1) Script générant un fichier de sauvegarde de la base de données

Ce script s’exécute sur le serveur de base de données. Il a pour but de créer un fichier .sql contenant une sauvegarde de la base de données du site prestashop :

>> nano dumpSQL.sh 1. #!/bin/bash 2. # Database credentials 3. user="root" 4. password="password" 5. host="localhost" 6. db_name="prestashop" 7. sv_name="prestashop1" 8. 9. # Other options 10. backup_path="/home/backup" 11. date=$(date +"%d-%b-%Y") 12. 13. # Set default file permissions 14. umask 177 15. 16. # Dump database into SQL file 17. mysqldump --user=$user --password=$password --host=$host $db_name > $backup_path/$sv_name-$date.sql 18. 19. # Delete files older than 30 days 20. find $backup_path/* -mtime +30 -exec rm {} \;

Nous y rajoutons une commande afin de supprimer les sauvegardes vieilles de plus de 30 jours.

3.4.2) Envoi du fichier vers le Serveur de Sauvegarde

Afin d’envoyer le fichier .sql au serveur de sauvegarde nous utilisons un nouveau script utilisant la commande rsync, installé au préalable sur tous les serveurs de base de données et celui de sauvegarde. Cela va permettre de synchroniser un dossier entre le serveur de base de données et le serveur de sauvegarde :

>> apt install rsync >> nano scriptrsync.sh 1. #!/bin/bash 2. 3. password="password" 4. date=$(date +"%d-%b-%Y") 5. 6. rsync -e ssh -avz /home/backup/* root@192.168.1.242:/home/backup

3.4.3) Automatisation de l’exécution du Script – Crontab

IW opte pour une sauvegarde journalière de leur base de données. Pour mettre cela en place nous allons utiliser l’utilitaire Crontab qui permet d’automatiser des tâches sur Linux. Nous allons appliquer la commande suivante et entrer les plans d’automatisation pour Crontab.

>> crontab –e 1. 0 8 * * 0-6 /chemin/absolu/vers/dumpSQL.sh 2. 0 9 * * 0-6 /chemin/absolu/vers/scriptrsync.sh

Crontab exécutera une sauvegarde tous les jours à 8 heure du matin et une synchronisation à 9 heure.

Page 21 of 38

3.5) Installation de PrestaShop

Avant de commencer l’installation de Prestashop nous allons lui créer une base de données et un utilisateur :

>> mysql MariaDB[(none)]> CREATE DATABASE prestashop; MariaDB[(none)]> GRANT ALL PRIVILEGES ON prestashop.* TO ‘prestauser’@’localhost’ IDENTIFIED BY ‘password’ WITH GRANT OPTION; MariaDB[(none)]> FLUSH PRIVILEGES;

3.5.1) Installation

Pour installer prestashop, nous devons tout d’abord télécharger son fichier compressé. La version 1.7.5.1.zip est la dernière version stable au moment de l’écriture de ce dossier :

>> wget –-no-check-certificate https://www.prestashop.com/download/old/prestashop_1.7.5.1.zip

Nous pouvons préparer son installation en décompressant le fichier et en lui accordant la possibilité d’être exécuté, écrit et lu :

>> mkdir /var/www/html/prestashop >> unzip prestashop 1.7.5.1.zip –d /var/www/html/prestashop >> chmod 777 –R /var/www/html/prestashop

Nous pouvons maintenant nous connecter à notre CMS et procéder à l’installation :

http://192.168.X.X/prestashop

IW devra renseigner les informations nécessaires à la création du backoffice du CMS Prestashop.

Afin de connecter le CMS à sa base de donnée, IW renseignera les informations nécessaires à la connexion en remote-access à sa base de données.

Page 22 of 38

Nous voulons désormais que Prestashop soit le site d’accueil de notre serveur Web. Un fichier .conf est créer avant d’être activé comme site actif :

>> nano /etc/apache2/sites-available/prestashop.conf 1. <VirtualHost *:80> 2. ServerAdmin admin@web-ppe.com 3. DocumentRoot /var/www/html/prestashop/ 4. ServerName web-ppe.com 5. ServerAlias www.web-ppe.com 6. 7. <Directory /var/www/html/prestashop/> 8. Options +FollowSymlinks 9. AllowOverride All 10. Require all granted 11. </Directory> 12. 13. ErrorLog ${APACHE_LOG_DIR}/error.log 14. CustomLog ${APACHE_LOG_DIR}/access.log combined 15. 16. </VirtualHost> >> a2ensite prestashop.conf >> a2dissite 000-default.conf

La dernière commande a pour but de désactiver la page d’accueil par défaut d’Apache2. Nous pouvons désormais nous connecter au site Prestashop directement via l’adresse IP et sans suffixe. (Voir annexe : 4.PRESTA) Afin d’accéder à l’interface administrateur il est important de supprimer le dossier d’installation :

>> rm –rf /var/www/html/prestashop/install

3.5.2) Mise en place de la réplication via Lsyncd

Le CMS Prestashop stocke ses images en local et ses bases de données contiennent des liens vers ces images. Cela rentre en conflit avec la réplication Master-to-Master de nos bases de données. Si un nouveau produit est rajouté via l’interface administrateur d’un Prestashop, son miroir va aussi posséder son nouvel article mais toutes images liées seront introuvables puisque non présentes sur le serveur miroir. Afin de résoudre ce problème nous allons utiliser l’utilitaire Lsyncd qui va nous permettre de synchroniser des dossiers clés de Prestashop entre chaque modification. Les dossiers clés sont :

/var/www/html/prestashop/img /var/www/html/prestashop/cache /var/www/html/prestashop/themes/classic/assets/cache /var/www/html/prestashop/override

Nous allons tout d’abord installer le prérequis rsync, Lsyncd et intégrer ce dernier aux services activés de Debian :

>> apt install rsync >> apt install lsyncd >> systemctl enable lsyncd

Page 23 of 38

Lsyncd requiert 3 fichiers, créés avec la commande touch (les dossiers sont créés avec mkdir si non présent) :

• /var/log/lsyncd/lsyncd.log • /var/log/lsyncd/lsyncd.status • /etc/lsyncd/lsyncd.conf.lua

Le fichier lsyncd.conf.lua contient la configuration de lsyncd. Nous allons le remplir afin que lsyncd synchronise les dossiers clés de Prestashop :

>> nano lsyncd.conf.lua 1. settings { 2. logfile = "/var/log/lsyncd/lsyncd.log", 3. statusFile = "/var/log/lsyncd/lsyncd.status", 4. statusIntervall = 1, 5. } 6. 7. sync { 8. default.rsyncssh, 9. source = "/var/www/html/prestashop/img", 10. host = "192.168.X.X", 11. targetdir = "/var/www/html/prestashop/img" 12. } 13. 14. sync { 15. default.rsyncssh, 16. source = "/var/www/html/prestashop/cache", 17. host = "192.168.X.X", 18. targetdir = "/var/www/html/prestashop/cache" 19. } 20. 21. sync { 22. default.rsyncssh, 23. source = "/var/www/html/prestashop/themes/classic/assets/cache", 24. host = "192.168.X.X", 25. targetdir = "/var/www/html/prestashop/themes/classic/assets/cache" 26. } 27. 28. sync { 29. default.rsyncssh, 30. source = "/var/www/html/prestashop/override", 31. host = "192.168.X.X", 32. targetdir = "/var/www/html/prestashop/override" 33. }

Après avoir relancé le service lsyncd, la synchronisation automatique se lancera selon le fichier lsyncd.conf.lua :

>> service lsyncd restart

Page 24 of 38

3.6) Zevenet

L’installation de Zevenet se fait comme un OS Debian. Il sera cependant demandé de fixer une adresse IP dès l’installation de Zevenet :

3.6.1) Installation

3.6.2) Configuration

Zevenet va servir de proxy à nos sites Web afin de permettre le LoadBalacing entre ces derniers. Nous devons donc configurer un proxy au préalable.

Nous allons attribuer à notre proxy l’IP sur laquelle on se connectera pour accéder au site Prestashop.

Page 25 of 38

Une fois le proxy créé, nous pouvons désormais créer notre « Ferme » qui contiendra nos serveurs Web :

Nous renseignons les IP de nos serveurs WEB dans la configuration de notre « ferme » afin d’activer le LoadBalancing entre eux via le proxy de Zevenet. (Voir annexe : 5.Farm)

Pour éviter un Single Point Of Failure au niveau de notre proxy, nous pouvons en faire un cluster. Zevenet supporte nativement cette fonction. Pour la mettre en place il nous faut deux serveurs Zevenet :

On renseigne les adresses IP de nos serveurs Zevenet et leur nom d’hôte local. Après avoir donné le mot de passe root du second Zevenet pour permettre le remote access, nous pouvons configurer la connexion RSA. Il nous est laissé le choix du type de cluster avant de valider la configuration. La configuration est transmise au second Zevenet qui se placera automatiquement en « Slave ».

Page 26 of 38

4) Sécurisation du réseau via ACL 4.1) Fiche matériel

L’entreprise possède déjà un Routeur de la marque Cisco de disponible.

Informations générales Désignation Cisco RV160 Marque Cisco Systems Modèle RV160-K9-G5

Routeur Type de Modem/Routeur Routeur Filaire Norme(s) réseau 4 X 10/100/1000 Mbps Sans-fil Non Wi-Fi Mesh (réseau maillé/multiroom) Non Dual-Band Non Compatible IPv6 Oui Connecteur(s) Réseau 1 X RJ45 Femelle (Management)

1 X SFP/GBIC 4 X LAN – Gigabit Ethernet – RJ45

Modem Modem Intégré Non Norme de modem ADSL 2+ Interface avec l'ordinateur RJ45 Femelle

Caractéristiques physiques Largeur 200 mm Hauteur 30 mm Profondeur 150 mm Poids 570 g

4.2) Configuration

Afin de sécuriser notre infrastructure, cette dernière sera placée derrière le Routeur Cisco qui sera placé derrière le Modem de l’ISP (Internet service Provider). Le WAN est configuré sur le DHCP du Modem. Côté LAN l’infrastructure est répartie sur 2 Vlan :

• Vlan 2 : LoadBalancing et Serveurs Web. o DHCP et plage d’adresses : 192.168.20.X ; 192.168.20.100-192.168.20.149 o Accès aux ports limité : MYSQL (3306) ; SSH (22) ; HTTP (80) ; HTTPS (443). o Accès au WAN.

• Vlan 3 : Bases de données et Serveur de sauvegarde. o DHCP et plage d’adresses : 192.168.30.X ; 192.168.30.100-192.168.30.149 o Accès aux port limité : MYSQL (3306) ; SSH (22) ; HTTP (80). o Pas d’accès au WAN.

Page 27 of 38

Pour mettre en place la limitation d’accès aux ports ainsi que limiter l’accès au WAN, nous mettons en place des ACL (Access Control List). La communication inter-vlan nécessaire au fonctionnement du service utilise le port 3306 (MYSQL) entre le Vlan 2 (Serveurs Web) et le Vlan 3 (Bases de données) :

Nous autorisons les Vlan 1 et 2 à accéder au WAN. Le Vlan 1 contiendra les outils d’administration de IW. IW se chargera de mettre en ligne leur domaine lié avec leurs sites WEB sur le Vlan 2 :

Afin de sécuriser en bloc et d’interdire toute communication non désirée, nous inscrivons une interdiction générale en dernière règle. Cette règle empêchera toute communication entre les Vlan à l’exception des règles faites précédemment :

5) Tests de fonctionnement de l’Infrastructure Réseau :

5.1) Accessibilité du site en local (Serveur Web & 2)

Situation Résultat attendu Résultat Commentaire Connexion depuis le Vlan 2 Affichage du site Affichage du site.

(Annexe 4.PRESTA) Déplacement possible sur le site.

Pour nos tests en local, nous procédons à limiter l’accès du site web à son propre Vlan. IW ne possède pas encore de SI.

Connexion depuis un Vlan autre

Page non trouvé Page non trouvé Comme prévu, le site n’est accessible en local que par son Vlan.

Connexion depuis le Vlan 2 avec bases de données déconnectées

Affichage du site – Erreur 500

Affichage du site – Erreur 500

Prestashop possède des pages pré-faites afin de signaler les erreurs.

Page 28 of 38

5.2) Accessibilité du site en local(Serveur Proxy – Load Balancing)

Situation Résultat attendu Résultat Commentaire Accès au proxy LoadBalancer

Redirection sur un site Web

Redirection effectué Ce test prouve uniquement le fonctionnement de la redirection

Multiple accès au proxy LoadBalancer

Redirection et répartition sur les sites Web contenu dans la Farm

Redirection et répartition effectué

Ce test démontre de l’efficacité du système Zevenet à répartir la charge sur les multiples sites Web.

Répartition avec un serveur Web Offline

Le serveur Web Offline est ignoré et ne reçoit pas de charge

Le LoadBalancer ignore effectivement le serveur Web Offline et le prend en compte dès sa remise en ligne

Le système de Ferme est efficace et palis aux avaries des serveurs Web.

Capacité de récupération du Cluster Zevenet après arrêt du fonctionnement du Maître

Promotion de l’esclave en maître et continuité du service

Succès du FailOver et promotion de l’esclave en maître

Le système Zevenet permet un FailOver automatique du système de LoadBalancing, évitant ainsi les SPOF.

5.3) Réplication des données

Situation Résultat attendu Résultat Commentaire Création d’un produit sur le site Prestashop 1

Réplication du produit sur le site Prestashop 2

Le produit apparait sur le site Prestashop 2

Les données de la base de données sont effectivement répliquées. L’image est répliquer du serveur Web 1 vers le serveur Web 2 via Lsyncd.

Création d’un produit sur le site Prestashop 2

Réplication des données mais pas de l’image

Réplication des données fonctionnelle. Le produit apparait mais l’image ne s’affiche pas car elle n’existe pas sur le Prestashop 1

La synchronisation Lsyncd est configurée en Master-Slave (Presta1-Presta2). Il faut utiliser l’administrateur Presta1 pour modifier le site et rajouter des produits.

Relance de la réplication Master-Master après une interruption de service d’un serveur de base de données

Relation Master-Master rétablie et bases de données mises à jour

Réplication rétabli et bases de données mises à jour selon les informations dans le buffer

La réplication Master-Master permet d’assurer la continuité du service. Après intervention humaine pour relancer le serveur, la réplication se relance automatiquement.

Relance de la réplication Master-Master après une interruption de service des serveurs de base de données

Relation Master-Master rétablie et bases de données mises à jour

Réplication non rétablie. Nécessite une intervention humaine.

Il nécessaire de relancer manuellement la relation Master-Master. (ref. 3.3.1) Mis en place d’une réplication de base de données)

Page 29 of 38

5.4) Réception du fichier de sauvegarde

Situation Résultat attendu Résultat Commentaire Exécution manuelle du script de dump de base de données

Réception d’un fichier .sql nommé après le site Prestashop utilisant cette base de données

Fichier reçu au format prestashop(1 ou 2)-(date).sql

Le script utilisant la commande mysqldump s’avère suffisant pour récupérer notre sauvegarde.

Exécution manuelle du script de synchronisation de sauvegarde

Copie du fichier .sql sur le serveur de sauvegarde via ssh (rsync)

Fichier reçu par synchronisation (rsync) sur le serveur de sauvegarde

Le script utilisant rsync garanti un transfert rapide et sécurisé de la sauvegarde tant que le port utilisé par le protocole ssh est opérationnel.

Exécution automatique des scripts précédemment testés via Crontab

Résultats précédents sans intervention humaine

Après activation de Crontab, les scripts s’exécutent selon les paramètres et nous obtenons les mêmes résultats que précédemment

Crontab nous permet d’automatiser cette tâche d’administration.

6) Conclusion Nous voilà avec une infrastructure d’hébergement WEB à haute disponibilité. Eviter les Single Point Of Failure s’est avéré être un challenge de taille car je n’avais pas accès aux onéreuses solutions professionnelles.

Ce Projet Personnel Encadré m’a vraiment poussé dans la recherche de l’optimisation et de la solution la plus adéquate à un problème entouré de contraintes. On peut véritablement créer des infrastructures à haute disponibilité tout en restant dans le domaine de l’Open Source ou du Community Version.

Page 30 of 38

Annexes :

Annexe 2.1.DEBIAN :

Annexe 2.2.DEBIAN :

Annexe 3.IP :

Page 31 of 38

Annexe 3.1.1.SSH :

Annexe 3.1.2.KEYGEN :

Page 32 of 38

Annexe 3.2.1.CONF :

# $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key # Ciphers and keying #RekeyLimit default none # Logging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m #PermitRootLogin prohibit-password #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 #PubkeyAuthentication yes # Expect .ssh/authorized_keys2 to be disregarded by default in future. #AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 #AuthorizedPrincipalsFile none #AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes

Page 33 of 38

#KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes #GSSAPIStrictAcceptorCheck yes #GSSAPIKeyExchange no # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM yes #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PermitTTY yes PrintMotd no #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #UsePrivilegeSeparation sandbox #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS no #PidFile /var/run/sshd.pid #MaxStartups 10:30:100 #PermitTunnel no #ChrootDirectory none #VersionAddendum none # no default banner path #Banner none # Allow client to pass locale environment variables AcceptEnv LANG LC_* # override default of no subsystems Subsystem sftp /usr/lib/openssh/sftp-server # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # PermitTTY no # ForceCommand cvs server Port 22 PermitRootLogin yes AllowUsers root

Page 34 of 38

Annexe 3.2.2.COPY :

Annexe 3.2.3.CONNECT :

Page 35 of 38

Annexe 3.3.APACHE :

Page 36 of 38

Annexe 3.4.1.PMA :

Annexe 3.4.2.PMA :

Annexe 3.4.3.PMA :

Page 37 of 38

Annexe 4.PRESTA :

Page 38 of 38

(Voir annexe : 5.Farm)