Création serveur web Debian 11 SECURISÉ + SERVEUR CA

Creation serveur web Debian 11 SECURISÉ + SERVEUR CA – Compte rendu

Dans le cadre de mon portfolio, j’ai réalisé l’installation d’un serveur web Debian 11 sur VirtualBox. Je vais vous expliquer les étapes que j’ai suivies pour installer Apache2 et phpMyAdmin sur cette machine.

Voici comment j’ai procédé :

Tout d’abord, j’ai créé une machine virtuelle avec les spécifications suivantes :

RAM : 2048 Mo
Processeurs : 1
Réseau : Pont
Disque virtuel : 20 Go

Ensuite, j’ai installé Debian 11 de base et configuré un utilisateur nommé Fred. J’ai choisi de ne pas installer l’interface graphique.

Une fois que j’ai pu accéder à la machine, j’ai configuré l’adresse IP comme suit :

IP : 172.16.189.10
Masque : 255.255.0.0
Passerelle : 172.16.0.1

Ensuite, j’ai procédé à la mise à jour des sources, APT et APT-GET en utilisant la commande :

sudo apt update

Une fois cela fait, j’ai installé Apache2 en exécutant :

sudo apt install apache2 -y

J’ai vérifié que le service Apache2 était actif en exécutant :

systemctl status apache2

Et en allant sur l’URL suivant :

http://172.16.189.10/

Nous pouvons vérifier que Apache est correctement installé lorsque nous voyons l’écran suivant :

Ensuite, j’ai installé PHP sur Debian 11 en utilisant la commande :

sudo apt install php php-cgi php-mysqli php-pear php-mbstring php-gettext libapache2-mod-php php-common php-phpseclib php-mysql -y

J’ai vérifié l’installation en exécutant :

php --version

J’ai installé MariaDB avec la commande :

sudo apt install mariadb-server mariadb-client -y

J’ai vérifié que le service MariaDB était actif en exécutant :

systemctl status mariadb

J’ai sécurisé MariaDB en exécutant :

sudo mysql_secure_installation

J’ai suivi les instructions pour définir un mot de passe root, supprimer les utilisateurs anonymes, interdire la connexion root à distance, supprimer la base de données de test et recharger les privilèges.

Creation d’un nouvel utilisateur MariaDB:

Je me suis connecté à la console MariaDB en utilisant la commande suivante :

sudo mysql -u root -p

J’ai entré le mot de passe root que j’avais précédemment défini lors de la sécurisation de MariaDB.
Une fois connecté à la console MariaDB, j’ai créé un nouvel utilisateur avec la commande suivante :

CREATE USER 'adminbdd1'@'localhost' IDENTIFIED BY 'azerty31';

J’ai accordé les privilèges nécessaires à cet utilisateur en utilisant la commande suivante :

GRANT ALL PRIVILEGES ON GSB_BDD1.* TO 'adminbdd'@'localhost' WITH GRANT OPTION;

Enfin, j’ai appliqué les modifications en exécutant la commande suivante :

FLUSH PRIVILEGES;
EXIT;

Ensuite pour télécharger et configurer phpMyAdmin, j’ai utilisé les étapes suivantes :

Téléchargement de la dernière version stable de phpMyAdmin en utilisant la commande :

wget -P Téléchargements https://www.phpmyadmin.net/downloads/phpMyAdmin-latest-all-languages.tar.gz

Vérification de la clé GPG de phpMyAdmin en téléchargeant le trousseau de clés avec la commande :

wget -P Téléchargements https://files.phpmyadmin.net/phpmyadmin.keyring

Importation du trousseau de clés en exécutant les commandes :

cd Téléchargements
gpg --import phpmyadmin.keyring

Téléchargement du fichier .asc correspondant à la version de phpMyAdmin avec la commande :

wget -P Téléchargements https://www.phpmyadmin.net/downloads/phpMyAdmin-latest-all-languages.tar.gz.asc

Vérification de la clé GPG avec la commande :

cd Téléchargements
gpg --verify phpMyAdmin-latest-all-languages.tar.gz.asc

Ensuite, j’ai créé un répertoire pour phpMyAdmin dans le répertoire racine du serveur Apache avec la commande :

sudo mkdir /var/www/html/phpmyadmin

J’ai décompressé les fichiers de phpMyAdmin dans ce répertoire avec la commande :

cd Téléchargements
sudo tar xvf phpMyAdmin-latest-all-languages.tar.gz --strip-components=1 -C /var/www/html/phpmyadmin

J’ai créé un fichier de configuration par défaut en utilisant la commande :

sudo cp /var/www/html/phpmyadmin/config.sample.inc.php /var/www/html/phpmyadmin/config.inc.php

J’ai ouvert le fichier config.inc.php avec un éditeur de texte, par exemple nano, et ajouté une phrase secrète en remplaçant la ligne $cfg['blowfish_secret'] = ''; par $cfg['blowfish_secret'] = 'ma_phrase_secrete';. J’ai choisi une phrase secrète complexe de mon choix. J’ai enregistré et quitté le fichier.

Ensuite, j’ai modifié les permissions du fichier config.inc.php avec la commande :

sudo chmod 660 /var/www/html/phpmyadmin/config.inc.php

J’ai changé le propriétaire du répertoire phpmyadmin avec la commande :

sudo chown -R www-data:www-data /var/www/html/phpmyadmin

Enfin, j’ai redémarré Apache avec la commande :

sudo systemctl restart apache2

phpMyAdmin est désormais accessible à l’adresse suivante :

http://172.16.189.10/phpmyadmin/

Nous pouvons maintenant nous connecter à phpmyadmin avec les informations d’identification par défaut

Utilisateur : root

MDP : Azerty31

Une fois que nous sommes connectés, nous pouvons créer une nouvelle base de données, que j’appellerai « GSB_BDD »

Maintenant nous devons remplir la base de données, heureusement nous avons deux fichiers à notre disposition, qui contiennent toutes les données du site web, nous allons d’abord aller dans « gsb_frais_structure.sql » et nous allons définir le bon nom de la base de données sur le fichier :

Après avoir modifié le fichier, nous pouvons enfin l’importer dans notre base de données, en choisissant la base de données et en cliquant sur le bouton « Importer », et nous choisirons les deux fichiers qui nous ont été donnés en classe pour alimenter les bases de données.

Et nous pouvons constater que les importations ont été couronnées de succès :

Nous pouvons maintenant commencer à transférer les fichiers du site web « appliFrais_2018 » qui ont été fournis pour ce TP dans notre serveur.

Pour transférer le dossier nécessaire, nous utiliserons la commande suivante sur notre ordinateur Windows (dans le même répertoire que le dossier à transférer) :

scp -r appliFrais_avecMysqli_2018 fred@172.16.189.10:

Nous allons maintenant trouver le dossier transféré dans notre répertoire personnel :

Nous ouvrons le fichier _bdGestionDonnees.lib.php à l’aide de la commande suivante :

nano appliFrais_avecMysqli_2018/include/_bdGestionDonnees.lib.php

Une fois dans le fichier, nous allons modifier les variables $login et $mdp et ajouter les informations d’identification de l’utilisateur que nous avons précédemment créé pour la base de données.

Now we will move this folder to the /var/www/html/ directory by using the following command:

cp -r appliFrais_avecMysqli_2018/ /var/www/html/

Once this file is in place we will rename it to GSB1 with the following command:

sudo mv appliFrais_avecMysqli_2018/ GSB1/

And technically this will allow us to get into the site by using the following URL:

http://172.16.189.10/GSB1/cSeConnecter.php

Now if we go to the database we can see the table « Visiteur » where we can see multiple passwords and usernames for the users of the site, we can try one of them to test the website is correctly connected to our database:

La connexion est réussie, nous allons maintenant répéter les étapes précédentes pour créer une DEUXIÈME base de données à laquelle le deuxième utilisateur aura accès.

GSB_BDD2.

Maintenant que la deuxième base de données est créée, nous allons créer un utilisateur qui n’aura accès qu’à cette base en suivant CETTE partie de la procédure et en utilisant la commande suivante :

Donc on utilise les commandes suivantes:

CREATE USER 'adminbdd2'@'localhost' IDENTIFIED BY 'azerty31';

GRANT ALL PRIVILEGES ON GSB_BDD2.* TO 'adminbdd2'@'localhost' WITH GRANT OPTION;

FLUSH PRIVILEGES;
EXIT;

Cela signifie que nous avons maintenant deux sites web, et que les deux sont connectés et seulement autorisés à se connecter à leurs bases de données respectives.

After changing the virtual hosts on /etc/apache2/sites-available/site1.conf et site2.conf we change the configurations of each website to give them a respective port. We add this new ports into the /etc/apache2/ports.conf

This will allow us to access a different website depending on the port, so we can do:

http://172.16.89.10:8080 pour GSB1 ou http://172.16.89.10:8081 pour GSB2.

Parametrage Serveur CA:

Maintenant, nous allons créer une nouvelle machine virtuelle sous Debian pour servir de serveur d’autorité de certification (CA).

Après avoir ajusté la configuration de notre nouvelle machine virtuelle (en changeant son adresse IP et son nom d’hôte), nous avons maintenant SRV-CA sur 172.16.189.11.

Maintenant, nous nous connectons à notre nouveau serveur en SSH et nous pouvons commencer la configuration.

Activation de mod_ssl:

J’ai activé le module mod_ssl dans le serveur WEB Apache en utilisant les commandes suivantes:

sudo a2enmod ssl

systemctl restart apache2

Génération du certificat SSL:

En utilisant la commande j’ai créé le certificat SSL sur le serveur CA:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/certs/selfsigned.key -out /etc/ssl/private/selfsigned.crt

J’ai fourni les informations nécessaires sur mon site web lorsqu’on me l’a demandé, en veillant à ce que le nom commun (Common Name) corresponde au nom d’hôte ou à l’adresse IP publique du serveur web.

Transfert du certificat SSL vers le SRV-WEB:

Une fois le certificat SSL généré sur le serveur d’autorité de certification (CA), j’ai transféré les fichiers de certificat vers le serveur web à l’aide de SCP .

cd /etc/ssl/
scp private/selfsigned.key fred@192.168.1.100:
#Cette commande transfère la clé directement dans le répertoire Home de l'utilisateur Fred dans le serveur web.

scp certs/selfsigned.crt fred@192.168.1.100:

Configuration du virtual host SSL sur le serveur web:

Tout d’abord, j’ai fait une copie du fichier default-ssl.conf dans le dossier apache sites-available, et je l’ai appelé Site1-SSL.conf.

mv /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/Site1-SSL.conf

J’ai édité le fichier de configuration Apache du virtual host en utilisant la commande sudo nano /etc/apache2/sites-available/Site1-SSL.conf sur le serveur web.

Site1-SSL.conf:


		ServerAdmin webmaster@localhost
		DocumentRoot /var/www/html/GSB1

		# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
		# error, crit, alert, emerg.
		# It is also possible to configure the loglevel for particular
		# modules, e.g.
		#LogLevel info ssl:warn

		ErrorLog $\{APACHE_LOG_DIR\}/error.log
		CustomLog $\{APACHE_LOG_DIR\}/access.log combined

		# For most configuration files from conf-available/, which are
		# enabled or disabled at a global level, it is possible to
		# include a line for only one particular virtual host. For example the
		# following line enables the CGI configuration for this host only
		# after it has been globally disabled with "a2disconf".
		#Include conf-available/serve-cgi-bin.conf

		#   SSL Engine Switch:
		#   Enable/Disable SSL for this virtual host.
		SSLEngine on

		#   A self-signed (snakeoil) certificate can be created by installing
		#   the ssl-cert package. See
		#   /usr/share/doc/apache2/README.Debian.gz for more info.
		#   If both key and certificate are stored in the same file, only the
		#   SSLCertificateFile directive is needed.
		SSLCertificateFile	/home/fred/selfsigned.crt
		SSLCertificateKeyFile /home/fred/selfsigned.key

		#   Server Certificate Chain:
		#   Point SSLCertificateChainFile at a file containing the
		#   concatenation of PEM encoded CA certificates which form the
		#   certificate chain for the server certificate. Alternatively
		#   the referenced file can be the same as SSLCertificateFile
		#   when the CA certificates are directly appended to the server
		#   certificate for convinience.
		#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt

		#   Certificate Authority (CA):
		#   Set the CA certificate verification path where to find CA
		#   certificates for client authentication or alternatively one
		#   huge file containing all of them (file must be PEM encoded)
		#   Note: Inside SSLCACertificatePath you need hash symlinks
		#		 to point to the certificate files. Use the provided
		#		 Makefile to update the hash symlinks after changes.
		#SSLCACertificatePath /etc/ssl/certs/
		#SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt

		#   Certificate Revocation Lists (CRL):
		#   Set the CA revocation path where to find CA CRLs for client
		#   authentication or alternatively one huge file containing all
		#   of them (file must be PEM encoded)
		#   Note: Inside SSLCARevocationPath you need hash symlinks
		#		 to point to the certificate files. Use the provided
		#		 Makefile to update the hash symlinks after changes.
		#SSLCARevocationPath /etc/apache2/ssl.crl/
		#SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl

		#   Client Authentication (Type):
		#   Client certificate verification type and depth.  Types are
		#   none, optional, require and optional_no_ca.  Depth is a
		#   number which specifies how deeply to verify the certificate
		#   issuer chain before deciding the certificate is not valid.
		#SSLVerifyClient require
		#SSLVerifyDepth  10

		#   SSL Engine Options:
		#   Set various options for the SSL engine.
		#   o FakeBasicAuth:
		#	 Translate the client X.509 into a Basic Authorisation.  This means that
		#	 the standard Auth/DBMAuth methods can be used for access control.  The
		#	 user name is the `one line' version of the client's X.509 certificate.
		#	 Note that no password is obtained from the user. Every entry in the user
		#	 file needs this password: `xxj31ZMTZzkVA'.
		#   o ExportCertData:
		#	 This exports two additional environment variables: SSL_CLIENT_CERT and
		#	 SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
		#	 server (always existing) and the client (only existing when client
		#	 authentication is used). This can be used to import the certificates
		#	 into CGI scripts.
		#   o StdEnvVars:
		#	 This exports the standard SSL/TLS related `SSL_*' environment variables.
		#	 Per default this exportation is switched off for performance reasons,
		#	 because the extraction step is an expensive operation and is usually
		#	 useless for serving static content. So one usually enables the
		#	 exportation for CGI and SSI requests only.
		#   o OptRenegotiate:
		#	 This enables optimized SSL connection renegotiation handling when SSL
		#	 directives are used in per-directory context.
		#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire

				SSLOptions +StdEnvVars

				SSLOptions +StdEnvVars

		#   SSL Protocol Adjustments:
		#   The safe and default but still SSL/TLS standard compliant shutdown
		#   approach is that mod_ssl sends the close notify alert but doesn't wait for
		#   the close notify alert from client. When you need a different shutdown
		#   approach you can use one of the following variables:
		#   o ssl-unclean-shutdown:
		#	 This forces an unclean shutdown when the connection is closed, i.e. no
		#	 SSL close notify alert is send or allowed to received.  This violates
		#	 the SSL/TLS standard but is needed for some brain-dead browsers. Use
		#	 this when you receive I/O errors because of the standard approach where
		#	 mod_ssl sends the close notify alert.
		#   o ssl-accurate-shutdown:
		#	 This forces an accurate shutdown when the connection is closed, i.e. a
		#	 SSL close notify alert is send and mod_ssl waits for the close notify
		#	 alert of the client. This is 100% SSL/TLS standard compliant, but in
		#	 practice often causes hanging connections with brain-dead browsers. Use
		#	 this only for browsers where you know that their SSL implementation
		#	 works correctly.
		#   Notice: Most problems of broken clients are also related to the HTTP
		#   keep-alive facility, so you usually additionally want to disable
		#   keep-alive for those clients, too. Use variable "nokeepalive" for this.
		#   Similarly, one has to force some clients to use HTTP/1.0 to workaround
		#   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
		#   "force-response-1.0" for this.
		# BrowserMatch "MSIE [2-6]" \
		#		nokeepalive ssl-unclean-shutdown \
		#		downgrade-1.0 force-response-1.0

 	DocumentRoot /var/www/html/GSB2
 	SSLEngine on
 	SSLCertificateFile /home/fred/selfsigned.crt
 	SSLCertificateKeyFile /home/fred/selfsigned.key

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Activation et test du virtual host SSL sur le serveur web:

J’ai activé le fichier de configuration pour le virtual host SSL en utilisant la commande sudo a2ensite Site1-SSL.conf sur le serveur web.
Ensuite, j’ai vérifié s’il y avait des erreurs de configuration en utilisant la commande sudo apache2ctl configtest. Vu qu’il n’y avait pas d’erreurs, j’ai rechargé Apache
Enfin, j’ai chargé le site web dans un navigateur en utilisant https://192.168.1.100:8080 et https://192.168.1.100:8081 et j’ai accepté les avertissements du navigateur concernant le certificat auto-signé. Après confirmation, le navigateur a réussi à afficher la page web.

NOTE IMPORTANTE, à la fin de ce projet, j’ai dû changer l’IP et le réseau des serveurs parce que j’ai dû travailler à la maison et que mon réseau privé est en 192.168.1.0/24, mais le fait de changer les serveurs à leur adresse IP d’origine fonctionnera si nous faisons fonctionner les VM sur le réseau de l’école.