-
Notifications
You must be signed in to change notification settings - Fork 0
TP06
Noms des auteurs : BONTEMS Antoine, SCHOONYANS Ann-Lore, LAMAND Cyril
Date de réalisation : 27/03/2025-30/03/2025
La sécurisation à bien été réalisée.
- Documentez ici les modifications effectuées sur votre infrastructure pour isoler la base de données.
- Etablissez une procédure de validation de l'isolation de la base de données.
On a mis en place les variables d'environnement ainsi que séparer le réseau en deux parties distinctes dans le docker-compose :


On peut voir que le web peut faire un ping vers php mais pas vers la db :

Et le php sait pinguer la db :

- Documentez les modifications effectuées
- Proposez une procédure de validation du fait que le serveur web ne peut pas effectuer d'opération dangereuse sur la DB.
On a ajouté dans woodytoys.sql le nouvel utilisateur :

Ainsi que rajouter le fichier my-resolv.cnf :

Afin de s'assurer que les privilèges soient corrects on peut réaliser des tests.
- Documentez la procédure de backup de votre base de données. On a réalisé cette commande :
docker exec tp6_db_1 mariadb-dump --all-databases -uroot -p"mypass"> /home/moiwesh/tp6/all-databases.sql
Cela permet de faire une sauvegarde de toutes les bases de données qu'on redirige vers /home/moiwesh/tp6 et ce fichier s'appellera all-databases.sql.

- Si vous avez réalisé le bonus proposé, documentez-le et prouvez son fonctionnement.
Pour accéder aux logs de la db, on fait : docker logs tp6_db_1 :


{: .question }
Que pense votre navigateur du certificat utilisé ? Pourquoi ? Expliquez la problématique qui est ici mise en évidence.
Dans le fichier nginx.cnf on a fait en sorte qu'il écoute sur le port 443 et que si on essaye d'accéder à partir du port 80, il était redirigé vers le port sécurisé.

Dans le docker-compose, on a fait en sorte qu'il prenne le certificat en compte.

On peux voir que le navigateur interprète cela comme une connexion pas privée mais que cela peut quand même fonctionner.


Documentez et prouvez la mise en place du certificat let's Encrypt sur vos virtuals hosts.
- Examinez les logs dans le fichier
/var/log/letsencrypt/letsencrypt.log- Trouvez les trois challenges ACME proposés par let's encrypt, et le token utilisé

- Trouvez la configuration nginx temporaire utilisée par certbot pour répondre au challenge

- Quelle est l'URL où se trouve le token sur votre serveur nginx?

- Voyez-vous le certificat reçu? De combien de parties se compose-t-il?
Il y a 3 parties:

- Où sont stockés les fichiers du certificat et de la clé privée générées par ```certbot```?
Ils sont stockés dans etc/letsencrypt/live/www.l2-7.ephec-ti.be
- Vérifiez votre configuration
nginx: qu'est ce qui a changé?![]()
- Vérifiez si votre site web possède à présent un certificat signé par Let's Encrypt et s'il est accepté par votre navigateur

- Examinez le certificat reçu avec l'outil OpenSSL, et identifiez les champs indiquant la signature du CA.

- Vérifiez également le statut HTTPS du second Virtual Host :
blog.lx-y.ephec-ti.be. Que se passe-t-il? Comment pouvez-vous corriger ça ?
On voit que on départ le blog est défini comme non sécurisé.

Pour cela, on doit lui créer aussi un certificat :


On peut voir que cela fonctionne :

Si vous avez réalisé l'obtention d'un certificat wildcard, documentez la procédure et prouvez qu'elle fonctionne sur votre domaine (par ex. via des screenshots).