Wiki d'activités IMA - Contributions de l’utilisateur [fr]

P4 IOT 2018

2019-01-26T18:41:12Z

Mcreteur : /* Documents rendus */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmé à travers elle.

Pour alimenter le device, nous avons ajouté à notre liste de matériel un transformateur 230VAC vers 12VDC pour alimenter les leds ainsi qu'un régulateur 12VDC vers 5VDC pour alimenter la Raspberry (2A). Ensuite la Raspberry se chargera d'alimenter les pilote de leds et l'ATMega328p.

==Séance 3==

===Carte électronique===
Durant cette séance nous avons finalisé le routage de la carte électronique suivant le circuit précédemment définit, et nous avons installé les librairies nécessaire à la programmation des pilotes de leds.

Nous avons également testé les 7-segments qui nous ont été fournit, et nous nous sommes rendus compte qu'ils étaient à cathode commune et donc fonctionnaient différemment de ce qui était indiqué sur la datasheet. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des registre à décalage pour contrôler toutes les sorties.

Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===programme Raspberry===

Durant cette séance, nous avons également pensé au soft qui sera embarqué dans la Raspberry. Nous avions décidé de configurer la Raspberry en accesspoint WiFi et de faire tourner un serveur web qui sera accessible lorsque l'utilisateur se connectera au WiFi de la Raspberry. En parallèle, un autre programme tournera sur la Raspberry et s'occupera du calcul du Timer et du contrôle des leds. Pour que le programme puisse communiquer avec le serveur nous avons plusieurs solutions à étudier : IPC, socket, écriture/lecture dans des fichiers.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû nous renseigner sur son fonctionnement et nous documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Programme Raspberry===

Pendant cette séance nous avons également finalisé le programme de la Raspberry et installé les librairies permettant d'utiliser le registre à décalage et les GPIO <code>WiringPi</code>.

Dans ce programme, après les initialisations, une socket UDP est créée pour recevoir la valeur initiale du Timer depuis le serveur web. La socket est par la suite fermée et le message reçu converti en entier. Puis deux threads sont lancés : Le premier qui permet le calcul du Timer en se basant sur la valeur initiale et en utilisant l'horloge physique de la Raspberry (fonction : <code>clock_gettime(CLOCK_REALTIME, &<timespec>);</code>), le deuxième thread contrôle les 7-segements après l'avoir parsé en unités et dizaines. Les deux threads communiquent entre eux avec un pipe et un système de verrou pour synchroniser l'envoi et la réception. Finalement les threads et le pipe sont fermés proprement.

Ce programme affiche les valeurs supérieures à 99 secondes en minutes et celle inférieures à 99 secondes en seconde. Le programme et disponible sur le git : https://github.com/ael-mess/raspberry-pi-timer/blob/master/pi.c

==Séance 6==

Durant cette séance nous avons combiné les deux programmes, et automatisé leur lancement. Nous avons créé un script shell qui lance le serveur web, puis dans une boucle infinie lance le Timer puis supprime les fichiers .json du controller du serveur web à la fin de chaque timer. Ce script a été mis dans <code>/etc/.rclocal</code> de la Raspberry en tache de fond, pour qu'il puissent être lancé à chaque allumage de la Raspberry même avant le loging.

===Test===

Pendant cette dernière séance nous avons également soudé une partie de nos composants pour faire des tests. Le test de la partie électronique à révélé un comportement anormal du circuit : des segments de leds restent allumés sans qu'aucune tension sur la base des transistors ne soit appliquée. Nous nous sommes assurés de corriger toutes les erreurs de soudure/contact mais nous n'avons pas pu trouver la source du problème. L’hypothèse qui a été émise est que la carte n'aillant pas été nettoyé avant la soudure, le contact n'était pas pareil pour tous les composants, et que donc le potentiel entre deux points reliés n'était pas identique (M.Thierry Flamen).

La partie logiciel elle, marche très bien sans aucun comportement anormal.

===Amélioration si plus temps===

- prendre plus de temps pour réaliser et tester la partie hardware.

- utiliser la socket pour l'envoie de chaque valeur du timer et non que pour la valeur initial. (parce que le timer calculé par le serveur web utilise la date de la Raspberry et n'est pas précis)

==Flyer==
[[Fichier:Flyer timer iot.jpeg|800px|center]]

=Documents rendus=

* [[Fichier:Timer IOT Web.zip]]
* https://github.com/ael-mess/raspberry-pi-timer/blob/master/pi.c
* [[Media:CarteElectroniqueIOTp4.zip|Fichiers carte électronique]]

Fichier:CarteElectroniqueIOTp4.zip

2019-01-26T18:38:18Z

Mcreteur :

P4 IOT 2018

2019-01-26T18:33:18Z

Mcreteur : /* Documents rendus */

P4 IOT 2018

2019-01-26T18:32:40Z

Mcreteur : /* Séance 6 */

P4 IOT 2018

2019-01-26T18:28:57Z

Mcreteur : /* Programme Raspberry */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmé à travers elle.

Pour alimenter le device, nous avons ajouté à notre liste de matériel un transformateur 230VAC vers 12VDC pour alimenter les leds ainsi qu'un régulateur 12VDC vers 5VDC pour alimenter la Raspberry (2A). Ensuite la Raspberry se chargera d'alimenter les pilote de leds et l'ATMega328p.

==Séance 3==

===Carte électronique===
Durant cette séance nous avons finalisé le routage de la carte électronique suivant le circuit précédemment définit, et nous avons installé les librairies nécessaire à la programmation des pilotes de leds.

Nous avons également testé les 7-segments qui nous ont été fournit, et nous nous sommes rendus compte qu'ils étaient à cathode commune et donc fonctionnaient différemment de ce qui était indiqué sur la datasheet. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des registre à décalage pour contrôler toutes les sorties.

Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===programme Raspberry===

Durant cette séance, nous avons également pensé au soft qui sera embarqué dans la Raspberry. Nous avions décidé de configurer la Raspberry en accesspoint WiFi et de faire tourner un serveur web qui sera accessible lorsque l'utilisateur se connectera au WiFi de la Raspberry. En parallèle, un autre programme tournera sur la Raspberry et s'occupera du calcul du Timer et du contrôle des leds. Pour que le programme puisse communiquer avec le serveur nous avons plusieurs solutions à étudier : IPC, socket, écriture/lecture dans des fichiers.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû nous renseigner sur son fonctionnement et nous documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Programme Raspberry===

Pendant cette séance nous avons également finalisé le programme de la Raspberry et installé les librairies permettant d'utiliser le registre à décalage et les GPIO <code>WiringPi</code>.

Dans ce programme, après les initialisations, une socket UDP est créée pour recevoir la valeur initiale du Timer depuis le serveur web. La socket est par la suite fermée et le message reçu converti en entier. Puis deux threads sont lancés : Le premier qui permet le calcul du Timer en se basant sur la valeur initiale et en utilisant l'horloge physique de la Raspberry (fonction : <code>clock_gettime(CLOCK_REALTIME, &<timespec>);</code>), le deuxième thread contrôle les 7-segements après l'avoir parsé en unités et dizaines. Les deux threads communiquent entre eux avec un pipe et un système de verrou pour synchroniser l'envoi et la réception. Finalement les threads et le pipe sont fermés proprement.

Ce programme affiche les valeurs supérieures à 99 secondes en minutes et celle inférieures à 99 secondes en seconde. Le programme et disponible sur le git : https://github.com/ael-mess/raspberry-pi-timer/blob/master/pi.c

==Séance 6==

Durant cette séance nous avons combiner les deux programmes, et automatiser leurs lancement. Nous avons crée un script shell qui lance le serveur web, puis dans une boucle infini lance le Timer puis supprime les fichiers .json du controllers du serveur web à la fin de chaque timer. Ce script à était mis dans <code>/etc/.rclocal</code> de la Raspberry en tache de fond, pour qu'il puissent être lancer à chaque allumage de la Raspberry même avant le loging.

===Test===

Pendant cette dernière séance nous avons également souder une partie de nos composants pour faire des tests. Le test de la partie électronique à révéler un comportement anormal du circuit : des segments de leds restent allumer sans que aucune tension sur la base des transistors ne soit appliquée. Nous nous sommes assuré de corriger toutes les erreurs de soudure/contact mais nous n'avions pas pu trouver la source du problème. L’hypothèse qui ont était émise est que la carte n'aillant pas était nettoyé avant la soudure, le contact n'était pas pareil pour tous les composants, et du coup le potentiel entre deux points reliées n'était pas identique (M.Thierry Flamen).

La partie logiciel elle, marche très bien sans aucun comportement anormal.

===Amélioration si plus temps===

- prendre plus de temps pour réaliser et tester la partie hardware.

- utiliser la socket pour l'envoie de chaque valeur du timer et non que pour la valeur initial. (parce que le timer calculer par le serveur web utilise la date de la Raspberry et n'est pas précis)

==Flyer==
[[Fichier:Flyer timer iot.jpeg|800px|center]]

=Documents rendus=

P4 IOT 2018

2019-01-26T18:22:12Z

Mcreteur :

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmé à travers elle.

Pour alimenter le device, nous avons ajouté à notre liste de matériel un transformateur 230VAC vers 12VDC pour alimenter les leds ainsi qu'un régulateur 12VDC vers 5VDC pour alimenter la Raspberry (2A). Ensuite la Raspberry se chargera d'alimenter les pilote de leds et l'ATMega328p.

==Séance 3==

===Carte électronique===
Durant cette séance nous avons finalisé le routage de la carte électronique suivant le circuit précédemment définit, et nous avons installé les librairies nécessaire à la programmation des pilotes de leds.

Nous avons également testé les 7-segments qui nous ont été fournit, et nous nous sommes rendus compte qu'ils étaient à cathode commune et donc fonctionnaient différemment de ce qui était indiqué sur la datasheet. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des registre à décalage pour contrôler toutes les sorties.

Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===programme Raspberry===

Durant cette séance, nous avons également pensé au soft qui sera embarqué dans la Raspberry. Nous avions décidé de configurer la Raspberry en accesspoint WiFi et de faire tourner un serveur web qui sera accessible lorsque l'utilisateur se connectera au WiFi de la Raspberry. En parallèle, un autre programme tournera sur la Raspberry et s'occupera du calcul du Timer et du contrôle des leds. Pour que le programme puisse communiquer avec le serveur nous avons plusieurs solutions à étudier : IPC, socket, écriture/lecture dans des fichiers.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû nous renseigner sur son fonctionnement et nous documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Programme Raspberry===

Pendant cette séance nous avons également finaliser le programme de la Raspberry et installer les librairies qui permettent d'utiliser le registre à décalage et les GPIO <code>WiringPi</code>.

Dans ce programme, après les initialisations, une socket UDP est crée pour recevoir la valeur initiale du Timer depuis le serveur web. La socket est par la suite fermée et le message reçu converti en Entier. Puis deux threads sont lancés : Le premier qui permet le calcul du Timer en se basant sur la valeur initial et en utilisant l'horloge physique de la Raspberry (fonction : <code>clock_gettime(CLOCK_REALTIME, &<timespec>);</code>), le deuxième thread contrôle les 7-segements après l'avoir parser en unités et dizaines. Les deux threads communiquent entre eux avec un pipe et un système de verrou pour synchroniser l'envoie et la réception. Finalement les threads et le pipe sont fermés proprement.

Ce programme affiche les valeurs supérieurs à 99 secondes en minutes et celle inférieurs à 99 secondes en seconde. Le programme et disponible sur le git : https://github.com/ael-mess/raspberry-pi-timer/blob/master/pi.c

==Séance 6==

Durant cette séance nous avons combiner les deux programmes, et automatiser leurs lancement. Nous avons crée un script shell qui lance le serveur web, puis dans une boucle infini lance le Timer puis supprime les fichiers .json du controllers du serveur web à la fin de chaque timer. Ce script à était mis dans <code>/etc/.rclocal</code> de la Raspberry en tache de fond, pour qu'il puissent être lancer à chaque allumage de la Raspberry même avant le loging.

===Test===

Pendant cette dernière séance nous avons également souder une partie de nos composants pour faire des tests. Le test de la partie électronique à révéler un comportement anormal du circuit : des segments de leds restent allumer sans que aucune tension sur la base des transistors ne soit appliquée. Nous nous sommes assuré de corriger toutes les erreurs de soudure/contact mais nous n'avions pas pu trouver la source du problème. L’hypothèse qui ont était émise est que la carte n'aillant pas était nettoyé avant la soudure, le contact n'était pas pareil pour tous les composants, et du coup le potentiel entre deux points reliées n'était pas identique (M.Thierry Flamen).

La partie logiciel elle, marche très bien sans aucun comportement anormal.

===Amélioration si plus temps===

- prendre plus de temps pour réaliser et tester la partie hardware.

- utiliser la socket pour l'envoie de chaque valeur du timer et non que pour la valeur initial. (parce que le timer calculer par le serveur web utilise la date de la Raspberry et n'est pas précis)

==Flyer==
[[Fichier:Flyer timer iot.jpeg|800px|center]]

=Documents rendus=

P4 IOT 2018

2019-01-26T18:19:57Z

Mcreteur : /* Serveur web */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmé à travers elle.

Pour alimenter le device, nous avons ajouté à notre liste de matériel un transformateur 230VAC vers 12VDC pour alimenter les leds ainsi qu'un régulateur 12VDC vers 5VDC pour alimenter la Raspberry (2A). Ensuite la Raspberry se chargera d'alimenter les pilote de leds et l'ATMega328p.

==Séance 3==

===Carte électronique===
Durant cette séance nous avons finalisé le routage de la carte électronique suivant le circuit précédemment définit, et nous avons installé les librairies nécessaire à la programmation des pilotes de leds.

Nous avons également testé les 7-segments qui nous ont été fournit, et nous nous sommes rendus compte qu'ils étaient à cathode commune et donc fonctionnaient différemment de ce qui était indiqué sur la datasheet. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des registre à décalage pour contrôler toutes les sorties.

Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===programme Raspberry===

Durant cette séance, nous avons également pensé au soft qui sera embarqué dans la Raspberry. Nous avions décidé de configurer la Raspberry en accesspoint WiFi et de faire tourner un serveur web qui sera accessible lorsque l'utilisateur se connectera au WiFi de la Raspberry. En parallèle, un autre programme tournera sur la Raspberry et s'occupera du calcul du Timer et du contrôle des leds. Pour que le programme puisse communiquer avec le serveur nous avons plusieurs solutions à étudier : IPC, socket, écriture/lecture dans des fichiers.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû nous renseigner sur son fonctionnement et nous documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Programme Raspberry===

Pendant cette séance nous avons également finaliser le programme de la Raspberry et installer les librairies qui permettent d'utiliser le registre à décalage et les GPIO <code>WiringPi</code>.

Dans ce programme, après les initialisations, une socket UDP est crée pour recevoir la valeur initiale du Timer depuis le serveur web. La socket est par la suite fermée et le message reçu converti en Entier. Puis deux threads sont lancés : Le premier qui permet le calcul du Timer en se basant sur la valeur initial et en utilisant l'horloge physique de la Raspberry (fonction : <code>clock_gettime(CLOCK_REALTIME, &<timespec>);</code>), le deuxième thread contrôle les 7-segements après l'avoir parser en unités et dizaines. Les deux threads communiquent entre eux avec un pipe et un système de verrou pour synchroniser l'envoie et la réception. Finalement les threads et le pipe sont fermés proprement.

Ce programme affiche les valeurs supérieurs à 99 secondes en minutes et celle inférieurs à 99 secondes en seconde. Le programme et disponible sur le git : https://github.com/ael-mess/raspberry-pi-timer/blob/master/pi.c

==Séance 6==

Durant cette séance nous avons combiner les deux programmes, et automatiser leurs lancement. Nous avons crée un script shell qui lance le serveur web, puis dans une boucle infini lance le Timer puis supprime les fichiers .json du controllers du serveur web à la fin de chaque timer. Ce script à était mis dans <code>/etc/.rclocal</code> de la Raspberry en tache de fond, pour qu'il puissent être lancer à chaque allumage de la Raspberry même avant le loging.

===Test===

Pendant cette dernière séance nous avons également souder une partie de nos composants pour faire des tests. Le test de la partie électronique à révéler un comportement anormal du circuit : des segments de leds restent allumer sans que aucune tension sur la base des transistors ne soit appliquée. Nous nous sommes assuré de corriger toutes les erreurs de soudure/contact mais nous n'avions pas pu trouver la source du problème. L’hypothèse qui ont était émise est que la carte n'aillant pas était nettoyé avant la soudure, le contact n'était pas pareil pour tous les composants, et du coup le potentiel entre deux points reliées n'était pas identique (M.Thierry Flamen).

La partie logiciel elle, marche très bien sans aucun comportement anormal.

===Amélioration si plus temps===

- prendre plus de temps pour réaliser et tester la partie hardware.

- utiliser la socket pour l'envoie de chaque valeur du timer et non que pour la valeur initial. (parce que le timer calculer par le serveur web utilise la date de la Raspberry et n'est pas précis)

==Flyer==
[[Fichier:Flyer timer iot.jpeg|800px|center]]

P4 IOT 2018

2019-01-26T18:19:20Z

Mcreteur : /* programme Raspberry */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmé à travers elle.

Pour alimenter le device, nous avons ajouté à notre liste de matériel un transformateur 230VAC vers 12VDC pour alimenter les leds ainsi qu'un régulateur 12VDC vers 5VDC pour alimenter la Raspberry (2A). Ensuite la Raspberry se chargera d'alimenter les pilote de leds et l'ATMega328p.

==Séance 3==

===Carte électronique===
Durant cette séance nous avons finalisé le routage de la carte électronique suivant le circuit précédemment définit, et nous avons installé les librairies nécessaire à la programmation des pilotes de leds.

Nous avons également testé les 7-segments qui nous ont été fournit, et nous nous sommes rendus compte qu'ils étaient à cathode commune et donc fonctionnaient différemment de ce qui était indiqué sur la datasheet. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des registre à décalage pour contrôler toutes les sorties.

Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===programme Raspberry===

Durant cette séance, nous avons également pensé au soft qui sera embarqué dans la Raspberry. Nous avions décidé de configurer la Raspberry en accesspoint WiFi et de faire tourner un serveur web qui sera accessible lorsque l'utilisateur se connectera au WiFi de la Raspberry. En parallèle, un autre programme tournera sur la Raspberry et s'occupera du calcul du Timer et du contrôle des leds. Pour que le programme puisse communiquer avec le serveur nous avons plusieurs solutions à étudier : IPC, socket, écriture/lecture dans des fichiers.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Programme Raspberry===

Pendant cette séance nous avons également finaliser le programme de la Raspberry et installer les librairies qui permettent d'utiliser le registre à décalage et les GPIO <code>WiringPi</code>.

Dans ce programme, après les initialisations, une socket UDP est crée pour recevoir la valeur initiale du Timer depuis le serveur web. La socket est par la suite fermée et le message reçu converti en Entier. Puis deux threads sont lancés : Le premier qui permet le calcul du Timer en se basant sur la valeur initial et en utilisant l'horloge physique de la Raspberry (fonction : <code>clock_gettime(CLOCK_REALTIME, &<timespec>);</code>), le deuxième thread contrôle les 7-segements après l'avoir parser en unités et dizaines. Les deux threads communiquent entre eux avec un pipe et un système de verrou pour synchroniser l'envoie et la réception. Finalement les threads et le pipe sont fermés proprement.

Ce programme affiche les valeurs supérieurs à 99 secondes en minutes et celle inférieurs à 99 secondes en seconde. Le programme et disponible sur le git : https://github.com/ael-mess/raspberry-pi-timer/blob/master/pi.c

==Séance 6==

Durant cette séance nous avons combiner les deux programmes, et automatiser leurs lancement. Nous avons crée un script shell qui lance le serveur web, puis dans une boucle infini lance le Timer puis supprime les fichiers .json du controllers du serveur web à la fin de chaque timer. Ce script à était mis dans <code>/etc/.rclocal</code> de la Raspberry en tache de fond, pour qu'il puissent être lancer à chaque allumage de la Raspberry même avant le loging.

===Test===

Pendant cette dernière séance nous avons également souder une partie de nos composants pour faire des tests. Le test de la partie électronique à révéler un comportement anormal du circuit : des segments de leds restent allumer sans que aucune tension sur la base des transistors ne soit appliquée. Nous nous sommes assuré de corriger toutes les erreurs de soudure/contact mais nous n'avions pas pu trouver la source du problème. L’hypothèse qui ont était émise est que la carte n'aillant pas était nettoyé avant la soudure, le contact n'était pas pareil pour tous les composants, et du coup le potentiel entre deux points reliées n'était pas identique (M.Thierry Flamen).

La partie logiciel elle, marche très bien sans aucun comportement anormal.

===Amélioration si plus temps===

- prendre plus de temps pour réaliser et tester la partie hardware.

- utiliser la socket pour l'envoie de chaque valeur du timer et non que pour la valeur initial. (parce que le timer calculer par le serveur web utilise la date de la Raspberry et n'est pas précis)

==Flyer==
[[Fichier:Flyer timer iot.jpeg|800px|center]]

P4 IOT 2018

2019-01-26T18:17:59Z

Mcreteur : /* Carte électronique */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmé à travers elle.

Pour alimenter le device, nous avons ajouté à notre liste de matériel un transformateur 230VAC vers 12VDC pour alimenter les leds ainsi qu'un régulateur 12VDC vers 5VDC pour alimenter la Raspberry (2A). Ensuite la Raspberry se chargera d'alimenter les pilote de leds et l'ATMega328p.

==Séance 3==

===Carte électronique===
Durant cette séance nous avons finalisé le routage de la carte électronique suivant le circuit précédemment définit, et nous avons installé les librairies nécessaire à la programmation des pilotes de leds.

Nous avons également testé les 7-segments qui nous ont été fournit, et nous nous sommes rendus compte qu'ils étaient à cathode commune et donc fonctionnaient différemment de ce qui était indiqué sur la datasheet. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des registre à décalage pour contrôler toutes les sorties.

Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===programme Raspberry===

Durant cette séance, nous avons également penser au soft qui sera embarqué dans la Raspberry. Nous avions décidé de configurer la Raspberry en accesspoint WiFi et de faire tourner un serveur web qui sera accessible lorsque l'utilisateur se connecte au WiFi de la Raspberry. En parallèle, un autre programme tournera sur la Raspberry et s'occupera du calcul du Timer et du contrôle des leds. pour que le programme puisse communiquer avec le serveur nous avons plusieurs solutions que nous allons étudier : ipc, socket, écriture/lecture dans des fichiers.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Programme Raspberry===

Pendant cette séance nous avons également finaliser le programme de la Raspberry et installer les librairies qui permettent d'utiliser le registre à décalage et les GPIO <code>WiringPi</code>.

Dans ce programme, après les initialisations, une socket UDP est crée pour recevoir la valeur initiale du Timer depuis le serveur web. La socket est par la suite fermée et le message reçu converti en Entier. Puis deux threads sont lancés : Le premier qui permet le calcul du Timer en se basant sur la valeur initial et en utilisant l'horloge physique de la Raspberry (fonction : <code>clock_gettime(CLOCK_REALTIME, &<timespec>);</code>), le deuxième thread contrôle les 7-segements après l'avoir parser en unités et dizaines. Les deux threads communiquent entre eux avec un pipe et un système de verrou pour synchroniser l'envoie et la réception. Finalement les threads et le pipe sont fermés proprement.

Ce programme affiche les valeurs supérieurs à 99 secondes en minutes et celle inférieurs à 99 secondes en seconde. Le programme et disponible sur le git : https://github.com/ael-mess/raspberry-pi-timer/blob/master/pi.c

==Séance 6==

Durant cette séance nous avons combiner les deux programmes, et automatiser leurs lancement. Nous avons crée un script shell qui lance le serveur web, puis dans une boucle infini lance le Timer puis supprime les fichiers .json du controllers du serveur web à la fin de chaque timer. Ce script à était mis dans <code>/etc/.rclocal</code> de la Raspberry en tache de fond, pour qu'il puissent être lancer à chaque allumage de la Raspberry même avant le loging.

===Test===

Pendant cette dernière séance nous avons également souder une partie de nos composants pour faire des tests. Le test de la partie électronique à révéler un comportement anormal du circuit : des segments de leds restent allumer sans que aucune tension sur la base des transistors ne soit appliquée. Nous nous sommes assuré de corriger toutes les erreurs de soudure/contact mais nous n'avions pas pu trouver la source du problème. L’hypothèse qui ont était émise est que la carte n'aillant pas était nettoyé avant la soudure, le contact n'était pas pareil pour tous les composants, et du coup le potentiel entre deux points reliées n'était pas identique (M.Thierry Flamen).

La partie logiciel elle, marche très bien sans aucun comportement anormal.

===Amélioration si plus temps===

- prendre plus de temps pour réaliser et tester la partie hardware.

- utiliser la socket pour l'envoie de chaque valeur du timer et non que pour la valeur initial. (parce que le timer calculer par le serveur web utilise la date de la Raspberry et n'est pas précis)

==Flyer==
[[Fichier:Flyer timer iot.jpeg|800px|center]]

P4 IOT 2018

2019-01-26T18:16:24Z

Mcreteur : /* Structuration du projet */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limitée en temps. On ne voudrait surtout pas rater cette dernière et ne pas avoir l'occasion de passer en revue l'ensemble de ses slides ! Le jury ne souhaite cependant pas faire office d'arbitre ou d'interrompre la personne soutenant. Ainsi, un timer connecté permettant d'indiquer le temps restant aux deux parties est placé sur la table. Ce timer fait également office de point d'accès et permet de se connecter à une page web ou les enseignants peuvent noter des commentaires que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste donc à réaliser un timer connecté, disposant de 4 afficheurs 7 segments, dont deux feront face à l'étudiant et les deux autres au jury. Nous utilisons une raspberry pi 3, et nous basons ainsi notre timer sur le timer ARM de cette dernière. La raspberry fait également office de point d'accès permettant de délivrer une page web qui permet de configurer le timer.
Le code controllant les afficheurs 7 segments sera réalisé en C.
Le serveur web sera basé sur le framework express de node js.
Le PCB sera réalisé sous Eagle.

=Réalisation=

==Matériel utilisé==

* 1 Raspberry pi 3
* 4 afficheurs 7 segments [http://www.kingbrightusa.com/images/catalog/SPEC/SA23-11SRWA.pdf SA23-11SRWA]
* 16 transistors PNP [http://njsemi.com/datasheets/2N2894.pdf 2N2894]
* 2 multiplexeurs [https://www.diodes.com/assets/Datasheets/74HCT595.pdf 74HCT595]
* 16 résistances 56 Ohms
* 16 résistances 1,2kOhms
* 2 capacités 100nF
* 1 capacité 10uF

==Séance 1==

===Recherche d'un sujet et clarification du cahier des charges===

Après avoir passé du temps à rechercher un sujet, nous nous sommes orienté vers le sujet proposé par les encadrants, le timer connecté. Nous avons alors passé le reste de la séance à effectuer des recherches sur le matériel à utiliser ainsi qu'à définir les fonctionnalités que présentera notre timer. Les fonctionnalités retenues sont les suivantes :

- Une application mobile permettra de contrôler le timer

- Si l'utilisateur est un membre du jury, il pourra modifier le timer

- Si l'utilisateur est une personne qui soutient, il ne pourra que consulter le timer

- Un système de vote sera disponible à partir de l'application

- Lorsqu'il restera 2 minutes sur le timer, le téléphone de l'utilisateur vibrera

- Le timer sera double face afin qu'il soit visible par le jury et l'étudiant

Finalement, nous avons été amené à revoir les fonctionnalités proposées au cours du projet par manque de temps. L'application a été remplacé par un site web. Le système de vote n'a pas été mis en place mais le membre du jury peut écrire des commentaires à la personne qui soutient à travers le site web. La fonctionnalité de vibration à été remplacée par un système de modification de la coloration du timer présent sur le site web à partir d'un certain temps restant.

Pendant cette séance, nous avons également établit une liste du matériel que nous utiliserons : une Raspberry pi pour faire tourner le serveur accessible en wifi, un transformateur 230VAC vers 5VDC pour alimenter la Raspberry, des afficheurs 7-segments, et un driver de leds pour utiliser le moins de sortie possible.

==Séance 2==

===Structuration du projet===

Lors de cette séance, des afficheurs 7-segments nous ont été fournis. Cependant, ils présentent la particularité d'être alimenté avec 12V. Les alimenter directement par la Raspberry qui elle peut fournir 5V n'est donc pas possible.

Nous anons essayé de trouver une solution pour le contrôle des LED. Nous en avons retenu deux :

- Utiliser des pilotes de LED [http://www.ti.com/lit/ds/symlink/tlc5947.pdf TLC5947]

- Utiliser des transistors

Nous avons alors décidé de partir sur les pilotes de LED pour plus de simplicité, ces derniers gérant eux mêmes le courant fournis aux LED. Après avoir pris cette décision, nous avons débuté la conception de la carte sous Eagle. Nous avons choisi ce logiciel car les toutes les footprint des composants utilisés sont disponibles sur le net.

Nous avons également pu trouver des bibliothèques python pour utiliser le pilote de leds, et commencer le programme. Nous utiliserons deux pilotes de leds en cascade que nous contrôlerons avec 3 GPIO de la Raspberry. Nous avons également prévu de rajouter un ATMega328p qui pourra lui aussi contrôler les pilotes si on modifie la position de trois jumper. L'ATMega sera relié à la Raspberry en série pour qu'il puissent être programmé à travers elle.

Pour alimenter le device, nous avons ajouté à notre liste de matériel un transformateur 230VAC vers 12VDC pour alimenter les leds ainsi qu'un régulateur 12VDC vers 5VDC pour alimenter la Raspberry (2A). Ensuite la Raspberry se chargera d'alimenter les pilote de leds et l'ATMega328p.

==Séance 3==

===Carte électronique===
Durant cette séance nous avons finalisé le routage de la carte électronique suivant le circuit précédemment définit, et nous avons installer les librairies nécessaire à la programmation des pilotes de leds.

Nous avons également tester les 7-segments qui nous ont étaient fournit, et nous nous sommes rendu compte qu'ils étaient à cathode commune et donc fonctionnaient différemment à ce qui a était indiqué sur la datasheet. Cela pose un problème puisque les pilotes de LED dont nous disposons ne sont pas compatibles avec cette configuration. Nous avons donc du nous tourner vers l'autre solution pour le contrôle des leds, celle avec les transistors. Disposant de 4 afficheurs à 7segments (+ le point), les GPIO de la Raspberry ne sont pas assez nombreux, nous avons donc du utiliser des registre à décalage pour contrôler toutes les sorties.

Nous avons alors passé cette séance à étudier les datasheet des différents composants et à établir un nouveau schéma pour la carte.

Les afficheurs 7-segments de devant ayant à afficher la même chose que ceux de derrière, nous les connecterons entre eux afin réduire de moitié la quantité de composants à utiliser.

===programme Raspberry===

Durant cette séance, nous avons également penser au soft qui sera embarqué dans la Raspberry. Nous avions décidé de configurer la Raspberry en accesspoint WiFi et de faire tourner un serveur web qui sera accessible lorsque l'utilisateur se connecte au WiFi de la Raspberry. En parallèle, un autre programme tournera sur la Raspberry et s'occupera du calcul du Timer et du contrôle des leds. pour que le programme puisse communiquer avec le serveur nous avons plusieurs solutions que nous allons étudier : ipc, socket, écriture/lecture dans des fichiers.

===Serveur web===

Selon la définition Wikipédia, Express est un framework nodejs permettant de mettre en place des applications web. Il s'agit du framework le plus utilisé dans ce but sous l'environnement NodeJS.
N'ayant jamais utilisé Express, nous avons dû se renseigner sur son fonctionnement et se documenter sur les possibilités du framework.
Express est basé sur une architecture typique MVC (Model-View-Controller). Nous pouvons définir des middlewares permettant de capturer les requêtes, de réaliser un traitement préalable, puis de renvoyer la page. Pour cela, il suffit de définir des routes, qui définirons les différentes requêtes HTTP possibles.

{| class="wikitable"
! style="text-align: center; font-weight:bold;" | Route
! style="text-align: center; font-weight:bold;" | Méthode
! style="text-align: center; font-weight:bold;" | Description
|-
| /
| GET
| Permet de réaliser un choix entre l'interface enseignant et étudiant
|-
| /prof
| GET
| Permet de parametrer le timer, en informant le nom du créateur du timer,
la durée de celui-ci en minutes, et l'étudiant en question.
|-
| /prof/timer
| GET
| Si un timer est configuré, affiche ce dernier, ainsi qu'un formulaire permettant
d'envoyer un commentaire.
|-
| /prof/timer
| POST
| Permet de traiter soit un nouveau commentaire, soit de lancer le timer
|-
| /etudiant
| GET
| Permet d'afficher les commentaires et un timer approximatif, qui vire au rouge lorsque
le temps devient critique (<2 minutes)
|}

Les routes étant fixés et définies, nous pouvons passer à la réalisation.

==Séance 4==

===Carte électronique===

Lors de cette séance, nous avons pu terminer la carte. Le schematic final est le suivant :

[[Fichier:SchematicP4IOT.png|center|1000px]]

Le PCB est le suivant :

[[Fichier:RoutageP4IOT.png|center|1000px]]

===Serveur web===
Afin de pouvoir communiquer avec le programme principal manipulant le véritable timer, il est nécessaire d'implémenter une sorte de communication inter-processus. Le choix est porté sur la mise en place d'une liaison sockets UDP, qui sont plus pratique dans notre cas que des sockets basés sur TCP.
Ainsi, le module 'dgram' (pour datagram, de UDP datagram socket), permet d'écouter pour un 'datagram' sur un port particulier, ou simplement de broadcaster un message.
Le serveur web permettra ainsi d'envoyer la valeur du timer en secondes, tandis que le programme principal en C écoutera sur un port spécifié, et lancera le timer dès la réception de la valeur.
Le code permettant l'envoi d'un message par socket UDP est simple à réaliser :

[[Fichier:Dgramtimer.png|600px]]

Nous avons décidés que le timer affiché sur les pages web est simplement à titre indicatif, soit, il ne représente pas réellement le véritable timer, dont la valeur est affiché sur les afficheurs 7 segments. Ce choix à été fait en raison du fait que nodejs et express ne tournent uniquement que sur un thread et ne permettent pas d'écouter sur un port et de rafraichir la page dès une réception.
Ainsi, dès le choix de la valeur du timer, nous sauvegardons la timestamp de fin de celui-ci et lançons le timer pour un compte à rebours vers cette valeur.

Les commentaires quant à eux sont enregistrés dans un fichier sous format JSON, et dans le cas d'une requête GET, une lecture de ce fichier est réalisée et les commentaires affichés, tandis que dans le cas d'une requête POST, le fichier est réécris en mémoire avec le nouveau commentaire.
L'identifiant d'un professeur commentant est défini sur le formulaire de choix du timer en ne spécifiant que le champ identifiant. La valeur de ce dernier est enregistré dans un cookie de navigateur.
Les informations relatives au timer, au nom de l'étudiant et au créateur du timer sont enregistrés dans un autre fichier JSON et récupérés au besoin.

[[Fichier:Entreeiot.png|300px]]
[[Fichier:CHOIXIOT.png|300px]]
[[Fichier:TimerProf.png|300px]]

==Séance 5==

===Gravure de la carte électronique===

Après avoir récupéré la carte gravée, nous nous sommes rendu compte qu'il y avait eu un problème de perçage. En effet, certains trous non présents sur le schéma de routage se trouvaient la carte, d'autres n'étaient pas du tout présent ou alors pas à la bonne place. Pourtant, nous n’apercevions aucun problème lors de la vérification des fichiers gerber avec http://www.gerber-viewer.com/. Nous avons alors passé pas mal de temps à rechercher la cause du problème avec Monsieur Flamen. Finalement, le problème provenait de la génération des fichiers gerber. Après avoir corrigé le problème, la carte a pu être regravée correctement.

===Configuration de la raspberry pi===

Nous configurons la raspberry afin d'agir en tant que point d'accès afin de pouvoir accéder à l'interface web :

Nous installons tout d'abord les paquets dnsmasq et hostapd, permettant de configurer le point d'accès et fournir le service DNS :
$ sudo apt-get install dnsmasq hostapd

Nous modifions le fichier de configuration de dhcpcd en ajoutant :
interface wlan0
static ip_address=192.168.4.1/24
nohook wpa_supplicant

Nous relançons ensuite le service dhcpcd.

Nous modifions ensuite le fichier de configuration de dnsmasq, qui va définir la plage d'IPs à attribuer :
interface=wlan0
dhcp-range=192.168.4.2,192.168.4.20,255.255.255.0,24h

Enfin, nous écrivons la configuration de notre point d'accès dans un fichier de configuration de hostapd :

interface=wlan0
driver=nl80211
ssid=TimerIOT
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=timeriot
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Enfin, nous lançons les processus hostapd et dnsmasq :
$ sudo systemctl start hostapd
$ sudo systemctl start dnsmasq

Nous rebootons enfin la raspberry. La page web est ainsi accessible en se connectant au point d'accès et en tapant http://192.168.4.1:3000 dans le navigateur.

===Programme Raspberry===

Pendant cette séance nous avons également finaliser le programme de la Raspberry et installer les librairies qui permettent d'utiliser le registre à décalage et les GPIO <code>WiringPi</code>.

Dans ce programme, après les initialisations, une socket UDP est crée pour recevoir la valeur initiale du Timer depuis le serveur web. La socket est par la suite fermée et le message reçu converti en Entier. Puis deux threads sont lancés : Le premier qui permet le calcul du Timer en se basant sur la valeur initial et en utilisant l'horloge physique de la Raspberry (fonction : <code>clock_gettime(CLOCK_REALTIME, &<timespec>);</code>), le deuxième thread contrôle les 7-segements après l'avoir parser en unités et dizaines. Les deux threads communiquent entre eux avec un pipe et un système de verrou pour synchroniser l'envoie et la réception. Finalement les threads et le pipe sont fermés proprement.

Ce programme affiche les valeurs supérieurs à 99 secondes en minutes et celle inférieurs à 99 secondes en seconde. Le programme et disponible sur le git : https://github.com/ael-mess/raspberry-pi-timer/blob/master/pi.c

==Séance 6==

Durant cette séance nous avons combiner les deux programmes, et automatiser leurs lancement. Nous avons crée un script shell qui lance le serveur web, puis dans une boucle infini lance le Timer puis supprime les fichiers .json du controllers du serveur web à la fin de chaque timer. Ce script à était mis dans <code>/etc/.rclocal</code> de la Raspberry en tache de fond, pour qu'il puissent être lancer à chaque allumage de la Raspberry même avant le loging.

===Test===

Pendant cette dernière séance nous avons également souder une partie de nos composants pour faire des tests. Le test de la partie électronique à révéler un comportement anormal du circuit : des segments de leds restent allumer sans que aucune tension sur la base des transistors ne soit appliquée. Nous nous sommes assuré de corriger toutes les erreurs de soudure/contact mais nous n'avions pas pu trouver la source du problème. L’hypothèse qui ont était émise est que la carte n'aillant pas était nettoyé avant la soudure, le contact n'était pas pareil pour tous les composants, et du coup le potentiel entre deux points reliées n'était pas identique (M.Thierry Flamen).

La partie logiciel elle, marche très bien sans aucun comportement anormal.

===Amélioration si plus temps===

- prendre plus de temps pour réaliser et tester la partie hardware.

- utiliser la socket pour l'envoie de chaque valeur du timer et non que pour la valeur initial. (parce que le timer calculer par le serveur web utilise la date de la Raspberry et n'est pas précis)

==Flyer==
[[Fichier:Flyer timer iot.jpeg|800px|center]]

P4 IOT 2018

2019-01-21T00:00:23Z

Mcreteur : /* Carte électronique */

P4 IOT 2018

2019-01-20T23:58:20Z

Mcreteur : /* Séance 4 */

Fichier:RoutageP4IOT.png

2019-01-20T23:56:53Z

Mcreteur :

Fichier:SchematicP4IOT.png

2019-01-20T23:54:28Z

Mcreteur :

P4 IOT 2018

2019-01-20T23:49:49Z

Mcreteur : /* Carte électronique */

P4 IOT 2018

2019-01-20T23:24:28Z

Mcreteur : /* Séance 2 */

P4 IOT 2018

2019-01-20T22:44:57Z

Mcreteur : /* Séance 3 */

P4 IOT 2018

2019-01-20T22:39:37Z

Mcreteur : /* Séance 2 */

P4 IOT 2018

2019-01-20T22:02:12Z

Mcreteur : /* Séance 5 */

P4 IOT 2018

2019-01-20T21:38:20Z

Mcreteur : /* Recherche d'un sujet et clarification du cahier des charges */

P4 IOT 2018

2019-01-20T21:37:50Z

Mcreteur : /* Séance 1 */

P4 IOT 2018

2019-01-20T20:47:56Z

Mcreteur : /* Réalisation */

P4 IOT 2018

2019-01-20T20:46:41Z

Mcreteur : /* Séance 1 */

P4 IOT 2018

2019-01-20T20:34:49Z

Mcreteur : /* Matériel utilisé */

P4 IOT 2018

2019-01-20T20:22:51Z

Mcreteur : /* Description du projet */

P4 IOT 2018

2019-01-20T20:22:34Z

Mcreteur : /* Description du projet */

P4 IOT 2018

2019-01-20T20:21:52Z

Mcreteur : /* Contexte */

P4 IOT 2018

2019-01-07T17:28:02Z

Mcreteur : Page créée avec « =Présentation du sujet = ==Contexte== ==Description du projet== =Réalisation= ==Matériel utilisé== ==Suivi de réalisation== »

=Présentation du sujet =

==Contexte==

==Description du projet==

=Réalisation=

==Matériel utilisé==

==Suivi de réalisation==

Option Internet des objets 2018/2019

2019-01-07T15:13:13Z

Mcreteur : /* Répartition des binômes */

= Répartition des binômes =

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules. Modifiez aussi l'intitulé de votre projet.

{| class="wikitable"
! Projet !! Elèves
|-
| [[P1_IOT_2018|Sujet 1]] || Raphael Morin, Brahim Ahammou
|-
| [[P2_IOT_2018|Smart Pen]] || Tony Jongmanee, Walid Ziyate
|-
| [[P3_IOT_2018|Sujet 3]] || Prénom Nom, Prénom Nom
|-
| [[P4_IOT_2018|Timer connecté]] || Naif Mehanna, Maxime Créteur, Amine El Messaoudi
|-
| [[P5_IOT_2018|Sujet 5]] || Prénom Nom, Prénom Nom
|-
| [[P6_IOT_2018|Sujet 6]] || Prénom Nom, Prénom Nom
|-
| [[P7_IOT_2018|Sujet 7]] || Prénom Nom, Prénom Nom
|-
|}

Option Internet des objets 2018/2019

2019-01-07T14:46:24Z

Mcreteur : /* Répartition des binômes */

= Répartition des binômes =

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules. Modifiez aussi l'intitulé de votre projet.

{| class="wikitable"
! Projet !! Elèves
|-
| [[P1_IOT_2018|Sujet 1]] || Raphael Morin, Brahim Ahammou
|-
| [[P2_IOT_2018|Stylo connecté]] || Tony Jongmanee, Walid Ziyate
|-
| [[P3_IOT_2018|Sujet 3]] || Prénom Nom, Prénom Nom
|-
| [[P4_IOT_2018|Sujet 4]] || Naif Mehanna, Maxime Créteur
|-
| [[P5_IOT_2018|Sujet 5]] || Prénom Nom, Prénom Nom
|-
| [[P6_IOT_2018|Sujet 6]] || Prénom Nom, Prénom Nom
|-
| [[P7_IOT_2018|Sujet 7]] || Prénom Nom, Prénom Nom
|-
|}

TP sysres IMA5sc 2018/2019 G7

2018-12-21T18:11:16Z

Mcreteur : /* 6. Réalisation */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1200px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===4.2 Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves.

===4.4 DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===4.3 Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

[[Fichier:Httpshercule.png|1000px|center]]

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/3.0/mods-enabled/eap :
default_eap_type = peap

- /etc/freeradius/3.0/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

Et enfin, nous lançons le service freeradius :
$ service freeradius restart

Nous passons ensuite à la modification de la configuration des points d'accès afin qu'ils prennent en compte notre serveur freeradius :

enable

conf t
aaa new-model
aaa authentication login eap_group17 group radius_group17
aaa group server radius radius_group17
server 193.48.57.183 auth-port 1812 acct-port 1813
radius-server host 193.48.57.183 auth-port 1812 acct-port 1813 key secretIMA5SC
end

conf t
dot11 ssid Hercule
vlan 17
authentication open eap eap_group17
authentication network-eap eap_group17
authentication key-management wpa
Mbssid Guest-mode
end

conf t
int dot11radio0
Mbssid
ssid Hercule
encryption vlan 17 mode ciphers aes-ccm tkip
end

conf t
int dot11radio0.17
encapsulation dot1Q 17
bridge-group 17
end

== 5. Tests d'intrusion ==
===5.3 Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlp2s0

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px|center]]

===5.2 Cassage de clé WEP===

Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlx40a5ef012c92

Nous affichons ensuite tout les point d'accés environnants protégés en WEP en utilisant la commande :

$ airodump-ng --encrypt wep wlan0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng --channel 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlan0mon

En parallèle, on simule une connexion au point d'accès pour récupérer le handshake :
$ aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:50:56 wlan0mon

On réalise le cassage :
$ aircrack-ng ./path_to_folder/cracotte07.cap

[[Fichier:cassagewep07.png|600px|center]]

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On monte le RAID dans notre VM :
mount /dev/md0 /mnt

On créé un fichier sur le RAID pour qu'il contienne des données. On ferme la VM et on lui retire la partition xvdc3 dans sa config.
On relance la VM. Puis on essaye de remonter le RAID :
En voulant remonter /dev/md0, un message nous indique que md0 n'existe pas. On lance alors la commande :
cat /proc/mdstat
Et on s'aperçoit que notre RAID est toujours présent, cette fois n'ayant plus que deux disques, mais apparaît sous le nom md127. On monte alors ce derrnier :
mount /dev/md127 /mnt
On retrouve alors bien le fichier créé initialement sur notre RAID. Lors de sa création, le fichier a été copié sur les 3 disques par le RAID. Ainsi, lorsque que nous avons supprimé un disque, cela n'a pas eu d'impact sur nos données.

[[Fichier:Raidhercule.png|600px|center]]

===6.2 Cryptage de données===

Dans notre cas, nous n'utilisons pas une carte SD. Nous créons cependant une partition de 1 Giga sur cordouan sur laquelle on travaillera :

$ lvcreate -L 1G -n /dev/virtual/hercule-crypt -v

Une fois cette action réalisée, et la partition intégrée au fichier de configuration de la machine virtuelle sous forme de volume, de nom xvdd1, nous récupérons les paquets lvm2 et cryptsetup.
Lorsque la récupération est terminée, nous sécurisons la partition de la manière suivante :

$ cryptsetup luksFormat -c aes -h sha256 /dev/xvdd1

Cette commande permet de formater la partiton au type LUKS et chiffre en AES avec un algorithme de hashage SHA256. Nous choisissons une phrase de chiffrement.

Une fois la partition chiffrée, nous ouvrons un volume dans notre partition chiffrée :

$ cryptsetup luksOpen /dev/xvdd1 home

Nous la formatons en ext4 :

$ mkfs -t ext4 /dev/mapper/home

Enfin, nous montons la partition sous /mnt :

$ mount -t ext4 /dev/mapper/home /mnt

Nous y créons ensuite un fichier texte. La suite de cette partie, qui est d'échanger les cartes SD, n'est pas réalisable dans notre cas.

TP sysres IMA5sc 2018/2019 G7

2018-12-21T18:10:49Z

Mcreteur : /* 5.2 Cassage de clé WEP */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1200px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===4.2 Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves.

===4.4 DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===4.3 Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

[[Fichier:Httpshercule.png|1000px|center]]

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/3.0/mods-enabled/eap :
default_eap_type = peap

- /etc/freeradius/3.0/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

Et enfin, nous lançons le service freeradius :
$ service freeradius restart

Nous passons ensuite à la modification de la configuration des points d'accès afin qu'ils prennent en compte notre serveur freeradius :

enable

conf t
aaa new-model
aaa authentication login eap_group17 group radius_group17
aaa group server radius radius_group17
server 193.48.57.183 auth-port 1812 acct-port 1813
radius-server host 193.48.57.183 auth-port 1812 acct-port 1813 key secretIMA5SC
end

conf t
dot11 ssid Hercule
vlan 17
authentication open eap eap_group17
authentication network-eap eap_group17
authentication key-management wpa
Mbssid Guest-mode
end

conf t
int dot11radio0
Mbssid
ssid Hercule
encryption vlan 17 mode ciphers aes-ccm tkip
end

conf t
int dot11radio0.17
encapsulation dot1Q 17
bridge-group 17
end

== 5. Tests d'intrusion ==
===5.3 Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlp2s0

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px|center]]

===5.2 Cassage de clé WEP===

Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlx40a5ef012c92

Nous affichons ensuite tout les point d'accés environnants protégés en WEP en utilisant la commande :

$ airodump-ng --encrypt wep wlan0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng --channel 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlan0mon

En parallèle, on simule une connexion au point d'accès pour récupérer le handshake :
$ aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:50:56 wlan0mon

On réalise le cassage :
$ aircrack-ng ./path_to_folder/cracotte07.cap

[[Fichier:cassagewep07.png|600px|center]]

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On monte le RAID dans notre VM :
mount /dev/md0 /mnt

On créé un fichier sur le RAID pour qu'il contienne des données. On ferme la VM et on lui retire la partition xvdc3 dans sa config.
On relance la VM. Puis on essaye de remonter le RAID :
En voulant remonter /dev/md0, un message nous indique que md0 n'existe pas. On lance alors la commande :
cat /proc/mdstat
Et on s'aperçoit que notre RAID est toujours présent, cette fois n'ayant plus que deux disques, mais apparaît sous le nom md127. On monte alors ce derrnier :
mount /dev/md127 /mnt
On retrouve alors bien le fichier créé initialement sur notre RAID. Lors de sa création, le fichier a été copié sur les 3 disques par le RAID. Ainsi, lorsque que nous avons supprimé un disque, cela n'a pas eu d'impact sur nos données.

[[Fichier:Raidhercule.png|600px]]

===6.2 Cryptage de données===

Dans notre cas, nous n'utilisons pas une carte SD. Nous créons cependant une partition de 1 Giga sur cordouan sur laquelle on travaillera :

$ lvcreate -L 1G -n /dev/virtual/hercule-crypt -v

Une fois cette action réalisée, et la partition intégrée au fichier de configuration de la machine virtuelle sous forme de volume, de nom xvdd1, nous récupérons les paquets lvm2 et cryptsetup.
Lorsque la récupération est terminée, nous sécurisons la partition de la manière suivante :

$ cryptsetup luksFormat -c aes -h sha256 /dev/xvdd1

Cette commande permet de formater la partiton au type LUKS et chiffre en AES avec un algorithme de hashage SHA256. Nous choisissons une phrase de chiffrement.

Une fois la partition chiffrée, nous ouvrons un volume dans notre partition chiffrée :

$ cryptsetup luksOpen /dev/xvdd1 home

Nous la formatons en ext4 :

$ mkfs -t ext4 /dev/mapper/home

Enfin, nous montons la partition sous /mnt :

$ mount -t ext4 /dev/mapper/home /mnt

Nous y créons ensuite un fichier texte. La suite de cette partie, qui est d'échanger les cartes SD, n'est pas réalisable dans notre cas.

TP sysres IMA5sc 2018/2019 G7

2018-12-21T18:10:32Z

Mcreteur : /* 5.3 Crackage de clé WPA */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1200px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===4.2 Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves.

===4.4 DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===4.3 Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

[[Fichier:Httpshercule.png|1000px|center]]

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/3.0/mods-enabled/eap :
default_eap_type = peap

- /etc/freeradius/3.0/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

Et enfin, nous lançons le service freeradius :
$ service freeradius restart

Nous passons ensuite à la modification de la configuration des points d'accès afin qu'ils prennent en compte notre serveur freeradius :

enable

conf t
aaa new-model
aaa authentication login eap_group17 group radius_group17
aaa group server radius radius_group17
server 193.48.57.183 auth-port 1812 acct-port 1813
radius-server host 193.48.57.183 auth-port 1812 acct-port 1813 key secretIMA5SC
end

conf t
dot11 ssid Hercule
vlan 17
authentication open eap eap_group17
authentication network-eap eap_group17
authentication key-management wpa
Mbssid Guest-mode
end

conf t
int dot11radio0
Mbssid
ssid Hercule
encryption vlan 17 mode ciphers aes-ccm tkip
end

conf t
int dot11radio0.17
encapsulation dot1Q 17
bridge-group 17
end

== 5. Tests d'intrusion ==
===5.3 Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlp2s0

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px|center]]

===5.2 Cassage de clé WEP===

Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlx40a5ef012c92

Nous affichons ensuite tout les point d'accés environnants protégés en WEP en utilisant la commande :

$ airodump-ng --encrypt wep wlan0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng --channel 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlan0mon

En parallèle, on simule une connexion au point d'accès pour récupérer le handshake :
$ aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:50:56 wlan0mon

On réalise le cassage :
$ aircrack-ng ./path_to_folder/cracotte07.cap

[[Fichier:cassagewep07.png|600px]]

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On monte le RAID dans notre VM :
mount /dev/md0 /mnt

On créé un fichier sur le RAID pour qu'il contienne des données. On ferme la VM et on lui retire la partition xvdc3 dans sa config.
On relance la VM. Puis on essaye de remonter le RAID :
En voulant remonter /dev/md0, un message nous indique que md0 n'existe pas. On lance alors la commande :
cat /proc/mdstat
Et on s'aperçoit que notre RAID est toujours présent, cette fois n'ayant plus que deux disques, mais apparaît sous le nom md127. On monte alors ce derrnier :
mount /dev/md127 /mnt
On retrouve alors bien le fichier créé initialement sur notre RAID. Lors de sa création, le fichier a été copié sur les 3 disques par le RAID. Ainsi, lorsque que nous avons supprimé un disque, cela n'a pas eu d'impact sur nos données.

[[Fichier:Raidhercule.png|600px]]

===6.2 Cryptage de données===

Dans notre cas, nous n'utilisons pas une carte SD. Nous créons cependant une partition de 1 Giga sur cordouan sur laquelle on travaillera :

$ lvcreate -L 1G -n /dev/virtual/hercule-crypt -v

Une fois cette action réalisée, et la partition intégrée au fichier de configuration de la machine virtuelle sous forme de volume, de nom xvdd1, nous récupérons les paquets lvm2 et cryptsetup.
Lorsque la récupération est terminée, nous sécurisons la partition de la manière suivante :

$ cryptsetup luksFormat -c aes -h sha256 /dev/xvdd1

Cette commande permet de formater la partiton au type LUKS et chiffre en AES avec un algorithme de hashage SHA256. Nous choisissons une phrase de chiffrement.

Une fois la partition chiffrée, nous ouvrons un volume dans notre partition chiffrée :

$ cryptsetup luksOpen /dev/xvdd1 home

Nous la formatons en ext4 :

$ mkfs -t ext4 /dev/mapper/home

Enfin, nous montons la partition sous /mnt :

$ mount -t ext4 /dev/mapper/home /mnt

Nous y créons ensuite un fichier texte. La suite de cette partie, qui est d'échanger les cartes SD, n'est pas réalisable dans notre cas.

TP sysres IMA5sc 2018/2019 G7

2018-12-21T18:09:54Z

Mcreteur : /* 4.3 Serveur Apache */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1200px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===4.2 Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves.

===4.4 DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===4.3 Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

[[Fichier:Httpshercule.png|1000px|center]]

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/3.0/mods-enabled/eap :
default_eap_type = peap

- /etc/freeradius/3.0/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

Et enfin, nous lançons le service freeradius :
$ service freeradius restart

Nous passons ensuite à la modification de la configuration des points d'accès afin qu'ils prennent en compte notre serveur freeradius :

enable

conf t
aaa new-model
aaa authentication login eap_group17 group radius_group17
aaa group server radius radius_group17
server 193.48.57.183 auth-port 1812 acct-port 1813
radius-server host 193.48.57.183 auth-port 1812 acct-port 1813 key secretIMA5SC
end

conf t
dot11 ssid Hercule
vlan 17
authentication open eap eap_group17
authentication network-eap eap_group17
authentication key-management wpa
Mbssid Guest-mode
end

conf t
int dot11radio0
Mbssid
ssid Hercule
encryption vlan 17 mode ciphers aes-ccm tkip
end

conf t
int dot11radio0.17
encapsulation dot1Q 17
bridge-group 17
end

== 5. Tests d'intrusion ==
===5.3 Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlp2s0

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px]]

===5.2 Cassage de clé WEP===

Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlx40a5ef012c92

Nous affichons ensuite tout les point d'accés environnants protégés en WEP en utilisant la commande :

$ airodump-ng --encrypt wep wlan0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng --channel 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlan0mon

En parallèle, on simule une connexion au point d'accès pour récupérer le handshake :
$ aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:50:56 wlan0mon

On réalise le cassage :
$ aircrack-ng ./path_to_folder/cracotte07.cap

[[Fichier:cassagewep07.png|600px]]

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On monte le RAID dans notre VM :
mount /dev/md0 /mnt

On créé un fichier sur le RAID pour qu'il contienne des données. On ferme la VM et on lui retire la partition xvdc3 dans sa config.
On relance la VM. Puis on essaye de remonter le RAID :
En voulant remonter /dev/md0, un message nous indique que md0 n'existe pas. On lance alors la commande :
cat /proc/mdstat
Et on s'aperçoit que notre RAID est toujours présent, cette fois n'ayant plus que deux disques, mais apparaît sous le nom md127. On monte alors ce derrnier :
mount /dev/md127 /mnt
On retrouve alors bien le fichier créé initialement sur notre RAID. Lors de sa création, le fichier a été copié sur les 3 disques par le RAID. Ainsi, lorsque que nous avons supprimé un disque, cela n'a pas eu d'impact sur nos données.

[[Fichier:Raidhercule.png|600px]]

===6.2 Cryptage de données===

Dans notre cas, nous n'utilisons pas une carte SD. Nous créons cependant une partition de 1 Giga sur cordouan sur laquelle on travaillera :

$ lvcreate -L 1G -n /dev/virtual/hercule-crypt -v

Une fois cette action réalisée, et la partition intégrée au fichier de configuration de la machine virtuelle sous forme de volume, de nom xvdd1, nous récupérons les paquets lvm2 et cryptsetup.
Lorsque la récupération est terminée, nous sécurisons la partition de la manière suivante :

$ cryptsetup luksFormat -c aes -h sha256 /dev/xvdd1

Cette commande permet de formater la partiton au type LUKS et chiffre en AES avec un algorithme de hashage SHA256. Nous choisissons une phrase de chiffrement.

Une fois la partition chiffrée, nous ouvrons un volume dans notre partition chiffrée :

$ cryptsetup luksOpen /dev/xvdd1 home

Nous la formatons en ext4 :

$ mkfs -t ext4 /dev/mapper/home

Enfin, nous montons la partition sous /mnt :

$ mount -t ext4 /dev/mapper/home /mnt

Nous y créons ensuite un fichier texte. La suite de cette partie, qui est d'échanger les cartes SD, n'est pas réalisable dans notre cas.

Fichier:Httpshercule.png

2018-12-21T18:08:38Z

Mcreteur :

TP sysres IMA5sc 2018/2019 G7

2018-12-21T18:03:55Z

Mcreteur : /* 4.Services internet */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1200px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===4.2 Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves.

===4.4 DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===4.3 Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/3.0/mods-enabled/eap :
default_eap_type = peap

- /etc/freeradius/3.0/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

Et enfin, nous lançons le service freeradius :
$ service freeradius restart

Nous passons ensuite à la modification de la configuration des points d'accès afin qu'ils prennent en compte notre serveur freeradius :

enable

conf t
aaa new-model
aaa authentication login eap_group17 group radius_group17
aaa group server radius radius_group17
server 193.48.57.183 auth-port 1812 acct-port 1813
radius-server host 193.48.57.183 auth-port 1812 acct-port 1813 key secretIMA5SC
end

conf t
dot11 ssid Hercule
vlan 17
authentication open eap eap_group17
authentication network-eap eap_group17
authentication key-management wpa
Mbssid Guest-mode
end

conf t
int dot11radio0
Mbssid
ssid Hercule
encryption vlan 17 mode ciphers aes-ccm tkip
end

conf t
int dot11radio0.17
encapsulation dot1Q 17
bridge-group 17
end

== 5. Tests d'intrusion ==
===5.3 Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlp2s0

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px]]

===5.2 Cassage de clé WEP===

Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlx40a5ef012c92

Nous affichons ensuite tout les point d'accés environnants protégés en WEP en utilisant la commande :

$ airodump-ng --encrypt wep wlan0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng --channel 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlan0mon

En parallèle, on simule une connexion au point d'accès pour récupérer le handshake :
$ aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:50:56 wlan0mon

On réalise le cassage :
$ aircrack-ng ./path_to_folder/cracotte07.cap

[[Fichier:cassagewep07.png|600px]]

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On monte le RAID dans notre VM :
mount /dev/md0 /mnt

On créé un fichier sur le RAID pour qu'il contienne des données. On ferme la VM et on lui retire la partition xvdc3 dans sa config.
On relance la VM. Puis on essaye de remonter le RAID :
En voulant remonter /dev/md0, un message nous indique que md0 n'existe pas. On lance alors la commande :
cat /proc/mdstat
Et on s'aperçoit que notre RAID est toujours présent, cette fois n'ayant plus que deux disques, mais apparaît sous le nom md127. On monte alors ce derrnier :
mount /dev/md127 /mnt
On retrouve alors bien le fichier créé initialement sur notre RAID. Lors de sa création, le fichier a été copié sur les 3 disques par le RAID. Ainsi, lorsque que nous avons supprimé un disque, cela n'a pas eu d'impact sur nos données.

[[Fichier:Raidhercule.png|600px]]

===6.2 Cryptage de données===

Dans notre cas, nous n'utilisons pas une carte SD. Nous créons cependant une partition de 1 Giga sur cordouan sur laquelle on travaillera :

$ lvcreate -L 1G -n /dev/virtual/hercule-crypt -v

Une fois cette action réalisée, et la partition intégrée au fichier de configuration de la machine virtuelle sous forme de volume, de nom xvdd1, nous récupérons les paquets lvm2 et cryptsetup.
Lorsque la récupération est terminée, nous sécurisons la partition de la manière suivante :

$ cryptsetup luksFormat -c aes -h sha256 /dev/xvdd1

Cette commande permet de formater la partiton au type LUKS et chiffre en AES avec un algorithme de hashage SHA256. Nous choisissons une phrase de chiffrement.

Une fois la partition chiffrée, nous ouvrons un volume dans notre partition chiffrée :

$ cryptsetup luksOpen /dev/xvdd1 home

Nous la formatons en ext4 :

$ mkfs -t ext4 /dev/mapper/home

Enfin, nous montons la partition sous /mnt :

$ mount -t ext4 /dev/mapper/home /mnt

Nous y créons ensuite un fichier texte. La suite de cette partie, qui est d'échanger les cartes SD, n'est pas réalisable dans notre cas.

TP sysres IMA5sc 2018/2019 G7

2018-12-21T18:03:34Z

Mcreteur : /* 4.Services internet */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1200px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===4.2 Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves

ZONES INVERSES A FAIRE

===4.4 DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===4.3 Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/3.0/mods-enabled/eap :
default_eap_type = peap

- /etc/freeradius/3.0/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

Et enfin, nous lançons le service freeradius :
$ service freeradius restart

Nous passons ensuite à la modification de la configuration des points d'accès afin qu'ils prennent en compte notre serveur freeradius :

enable

conf t
aaa new-model
aaa authentication login eap_group17 group radius_group17
aaa group server radius radius_group17
server 193.48.57.183 auth-port 1812 acct-port 1813
radius-server host 193.48.57.183 auth-port 1812 acct-port 1813 key secretIMA5SC
end

conf t
dot11 ssid Hercule
vlan 17
authentication open eap eap_group17
authentication network-eap eap_group17
authentication key-management wpa
Mbssid Guest-mode
end

conf t
int dot11radio0
Mbssid
ssid Hercule
encryption vlan 17 mode ciphers aes-ccm tkip
end

conf t
int dot11radio0.17
encapsulation dot1Q 17
bridge-group 17
end

== 5. Tests d'intrusion ==
===5.3 Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlp2s0

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px]]

===5.2 Cassage de clé WEP===

Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlx40a5ef012c92

Nous affichons ensuite tout les point d'accés environnants protégés en WEP en utilisant la commande :

$ airodump-ng --encrypt wep wlan0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng --channel 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlan0mon

En parallèle, on simule une connexion au point d'accès pour récupérer le handshake :
$ aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:50:56 wlan0mon

On réalise le cassage :
$ aircrack-ng ./path_to_folder/cracotte07.cap

[[Fichier:cassagewep07.png|600px]]

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On monte le RAID dans notre VM :
mount /dev/md0 /mnt

On créé un fichier sur le RAID pour qu'il contienne des données. On ferme la VM et on lui retire la partition xvdc3 dans sa config.
On relance la VM. Puis on essaye de remonter le RAID :
En voulant remonter /dev/md0, un message nous indique que md0 n'existe pas. On lance alors la commande :
cat /proc/mdstat
Et on s'aperçoit que notre RAID est toujours présent, cette fois n'ayant plus que deux disques, mais apparaît sous le nom md127. On monte alors ce derrnier :
mount /dev/md127 /mnt
On retrouve alors bien le fichier créé initialement sur notre RAID. Lors de sa création, le fichier a été copié sur les 3 disques par le RAID. Ainsi, lorsque que nous avons supprimé un disque, cela n'a pas eu d'impact sur nos données.

[[Fichier:Raidhercule.png|600px]]

===6.2 Cryptage de données===

Dans notre cas, nous n'utilisons pas une carte SD. Nous créons cependant une partition de 1 Giga sur cordouan sur laquelle on travaillera :

$ lvcreate -L 1G -n /dev/virtual/hercule-crypt -v

Une fois cette action réalisée, et la partition intégrée au fichier de configuration de la machine virtuelle sous forme de volume, de nom xvdd1, nous récupérons les paquets lvm2 et cryptsetup.
Lorsque la récupération est terminée, nous sécurisons la partition de la manière suivante :

$ cryptsetup luksFormat -c aes -h sha256 /dev/xvdd1

Cette commande permet de formater la partiton au type LUKS et chiffre en AES avec un algorithme de hashage SHA256. Nous choisissons une phrase de chiffrement.

Une fois la partition chiffrée, nous ouvrons un volume dans notre partition chiffrée :

$ cryptsetup luksOpen /dev/xvdd1 home

Nous la formatons en ext4 :

$ mkfs -t ext4 /dev/mapper/home

Enfin, nous montons la partition sous /mnt :

$ mount -t ext4 /dev/mapper/home /mnt

Nous y créons ensuite un fichier texte. La suite de cette partie, qui est d'échanger les cartes SD, n'est pas réalisable dans notre cas.

TP sysres IMA5sc 2018/2019 G7

2018-12-21T18:02:31Z

Mcreteur : /* 5. Tests d'intrusion */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1200px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves

ZONES INVERSES A FAIRE

===DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/3.0/mods-enabled/eap :
default_eap_type = peap

- /etc/freeradius/3.0/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

Et enfin, nous lançons le service freeradius :
$ service freeradius restart

Nous passons ensuite à la modification de la configuration des points d'accès afin qu'ils prennent en compte notre serveur freeradius :

enable

conf t
aaa new-model
aaa authentication login eap_group17 group radius_group17
aaa group server radius radius_group17
server 193.48.57.183 auth-port 1812 acct-port 1813
radius-server host 193.48.57.183 auth-port 1812 acct-port 1813 key secretIMA5SC
end

conf t
dot11 ssid Hercule
vlan 17
authentication open eap eap_group17
authentication network-eap eap_group17
authentication key-management wpa
Mbssid Guest-mode
end

conf t
int dot11radio0
Mbssid
ssid Hercule
encryption vlan 17 mode ciphers aes-ccm tkip
end

conf t
int dot11radio0.17
encapsulation dot1Q 17
bridge-group 17
end

== 5. Tests d'intrusion ==
===5.3 Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlp2s0

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px]]

===5.2 Cassage de clé WEP===

Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlx40a5ef012c92

Nous affichons ensuite tout les point d'accés environnants protégés en WEP en utilisant la commande :

$ airodump-ng --encrypt wep wlan0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng --channel 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlan0mon

En parallèle, on simule une connexion au point d'accès pour récupérer le handshake :
$ aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:50:56 wlan0mon

On réalise le cassage :
$ aircrack-ng ./path_to_folder/cracotte07.cap

[[Fichier:cassagewep07.png|600px]]

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On monte le RAID dans notre VM :
mount /dev/md0 /mnt

On créé un fichier sur le RAID pour qu'il contienne des données. On ferme la VM et on lui retire la partition xvdc3 dans sa config.
On relance la VM. Puis on essaye de remonter le RAID :
En voulant remonter /dev/md0, un message nous indique que md0 n'existe pas. On lance alors la commande :
cat /proc/mdstat
Et on s'aperçoit que notre RAID est toujours présent, cette fois n'ayant plus que deux disques, mais apparaît sous le nom md127. On monte alors ce derrnier :
mount /dev/md127 /mnt
On retrouve alors bien le fichier créé initialement sur notre RAID. Lors de sa création, le fichier a été copié sur les 3 disques par le RAID. Ainsi, lorsque que nous avons supprimé un disque, cela n'a pas eu d'impact sur nos données.

[[Fichier:Raidhercule.png|600px]]

===6.2 Cryptage de données===

Dans notre cas, nous n'utilisons pas une carte SD. Nous créons cependant une partition de 1 Giga sur cordouan sur laquelle on travaillera :

$ lvcreate -L 1G -n /dev/virtual/hercule-crypt -v

Une fois cette action réalisée, et la partition intégrée au fichier de configuration de la machine virtuelle sous forme de volume, de nom xvdd1, nous récupérons les paquets lvm2 et cryptsetup.
Lorsque la récupération est terminée, nous sécurisons la partition de la manière suivante :

$ cryptsetup luksFormat -c aes -h sha256 /dev/xvdd1

Cette commande permet de formater la partiton au type LUKS et chiffre en AES avec un algorithme de hashage SHA256. Nous choisissons une phrase de chiffrement.

Une fois la partition chiffrée, nous ouvrons un volume dans notre partition chiffrée :

$ cryptsetup luksOpen /dev/xvdd1 home

Nous la formatons en ext4 :

$ mkfs -t ext4 /dev/mapper/home

Enfin, nous montons la partition sous /mnt :

$ mount -t ext4 /dev/mapper/home /mnt

Nous y créons ensuite un fichier texte. La suite de cette partie, qui est d'échanger les cartes SD, n'est pas réalisable dans notre cas.

TP sysres IMA5sc 2018/2019 G7

2018-12-21T18:01:40Z

Mcreteur : /* 6. Réalisation */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1200px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves

ZONES INVERSES A FAIRE

===DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/3.0/mods-enabled/eap :
default_eap_type = peap

- /etc/freeradius/3.0/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

Et enfin, nous lançons le service freeradius :
$ service freeradius restart

Nous passons ensuite à la modification de la configuration des points d'accès afin qu'ils prennent en compte notre serveur freeradius :

enable

conf t
aaa new-model
aaa authentication login eap_group17 group radius_group17
aaa group server radius radius_group17
server 193.48.57.183 auth-port 1812 acct-port 1813
radius-server host 193.48.57.183 auth-port 1812 acct-port 1813 key secretIMA5SC
end

conf t
dot11 ssid Hercule
vlan 17
authentication open eap eap_group17
authentication network-eap eap_group17
authentication key-management wpa
Mbssid Guest-mode
end

conf t
int dot11radio0
Mbssid
ssid Hercule
encryption vlan 17 mode ciphers aes-ccm tkip
end

conf t
int dot11radio0.17
encapsulation dot1Q 17
bridge-group 17
end

== 5. Tests d'intrusion ==
===Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlp2s0

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px]]

===Cassage de clé WEP===

Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlx40a5ef012c92

Nous affichons ensuite tout les point d'accés environnants protégés en WEP en utilisant la commande :

$ airodump-ng --encrypt wep wlan0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng --channel 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlan0mon

En parallèle, on simule une connexion au point d'accès pour récupérer le handshake :
$ aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:50:56 wlan0mon

On réalise le cassage :
$ aircrack-ng ./path_to_folder/cracotte07.cap

[[Fichier:cassagewep07.png|600px]]

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On monte le RAID dans notre VM :
mount /dev/md0 /mnt

On créé un fichier sur le RAID pour qu'il contienne des données. On ferme la VM et on lui retire la partition xvdc3 dans sa config.
On relance la VM. Puis on essaye de remonter le RAID :
En voulant remonter /dev/md0, un message nous indique que md0 n'existe pas. On lance alors la commande :
cat /proc/mdstat
Et on s'aperçoit que notre RAID est toujours présent, cette fois n'ayant plus que deux disques, mais apparaît sous le nom md127. On monte alors ce derrnier :
mount /dev/md127 /mnt
On retrouve alors bien le fichier créé initialement sur notre RAID. Lors de sa création, le fichier a été copié sur les 3 disques par le RAID. Ainsi, lorsque que nous avons supprimé un disque, cela n'a pas eu d'impact sur nos données.

[[Fichier:Raidhercule.png|600px]]

===6.2 Cryptage de données===

Dans notre cas, nous n'utilisons pas une carte SD. Nous créons cependant une partition de 1 Giga sur cordouan sur laquelle on travaillera :

$ lvcreate -L 1G -n /dev/virtual/hercule-crypt -v

Une fois cette action réalisée, et la partition intégrée au fichier de configuration de la machine virtuelle sous forme de volume, de nom xvdd1, nous récupérons les paquets lvm2 et cryptsetup.
Lorsque la récupération est terminée, nous sécurisons la partition de la manière suivante :

$ cryptsetup luksFormat -c aes -h sha256 /dev/xvdd1

Cette commande permet de formater la partiton au type LUKS et chiffre en AES avec un algorithme de hashage SHA256. Nous choisissons une phrase de chiffrement.

Une fois la partition chiffrée, nous ouvrons un volume dans notre partition chiffrée :

$ cryptsetup luksOpen /dev/xvdd1 home

Nous la formatons en ext4 :

$ mkfs -t ext4 /dev/mapper/home

Enfin, nous montons la partition sous /mnt :

$ mount -t ext4 /dev/mapper/home /mnt

Nous y créons ensuite un fichier texte. La suite de cette partie, qui est d'échanger les cartes SD, n'est pas réalisable dans notre cas.

TP sysres IMA5sc 2018/2019 G7

2018-12-21T18:01:04Z

Mcreteur : /* 6.1 Cryptage de données */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1200px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves

ZONES INVERSES A FAIRE

===DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/3.0/mods-enabled/eap :
default_eap_type = peap

- /etc/freeradius/3.0/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

Et enfin, nous lançons le service freeradius :
$ service freeradius restart

Nous passons ensuite à la modification de la configuration des points d'accès afin qu'ils prennent en compte notre serveur freeradius :

enable

conf t
aaa new-model
aaa authentication login eap_group17 group radius_group17
aaa group server radius radius_group17
server 193.48.57.183 auth-port 1812 acct-port 1813
radius-server host 193.48.57.183 auth-port 1812 acct-port 1813 key secretIMA5SC
end

conf t
dot11 ssid Hercule
vlan 17
authentication open eap eap_group17
authentication network-eap eap_group17
authentication key-management wpa
Mbssid Guest-mode
end

conf t
int dot11radio0
Mbssid
ssid Hercule
encryption vlan 17 mode ciphers aes-ccm tkip
end

conf t
int dot11radio0.17
encapsulation dot1Q 17
bridge-group 17
end

== 5. Tests d'intrusion ==
===Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlp2s0

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px]]

===Cassage de clé WEP===

Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlx40a5ef012c92

Nous affichons ensuite tout les point d'accés environnants protégés en WEP en utilisant la commande :

$ airodump-ng --encrypt wep wlan0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng --channel 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlan0mon

En parallèle, on simule une connexion au point d'accès pour récupérer le handshake :
$ aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:50:56 wlan0mon

On réalise le cassage :
$ aircrack-ng ./path_to_folder/cracotte07.cap

[[Fichier:cassagewep07.png|600px]]

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On monte le RAID dans notre VM :
mount /dev/md0 /mnt

On créé un fichier sur le RAID pour qu'il contienne des données. On ferme la VM et on lui retire la partition xvdc3 dans sa config.
On relance la VM. Puis on essaye de remonter le RAID :
En voulant remonter /dev/md0, un message nous indique que md0 n'existe pas. On lance alors la commande :
cat /proc/mdstat
Et on s'aperçoit que notre RAID est toujours présent, cette fois n'ayant plus que deux disques, mais apparaît sous le nom md127. On monte alors ce derrnier :
mount /dev/md127 /mnt
On retrouve alors bien le fichier créé initialement sur notre RAID. Lors de sa création, le fichier a été copié sur les 3 disques par le RAID. Ainsi, lorsque que nous avons supprimé un disque, cela n'a pas eu d'impact sur nos données.

[[Fichier:Raidhercule.png|600px]]

===6.1 Cryptage de données===

Dans notre cas, nous n'utilisons pas une carte SD. Nous créons cependant une partition de 1 Giga sur cordouan sur laquelle on travaillera :

$ lvcreate -L 1G -n /dev/virtual/hercule-crypt -v

Une fois cette action réalisée, et la partition intégrée au fichier de configuration de la machine virtuelle sous forme de volume, de nom xvdd1, nous récupérons les paquets lvm2 et cryptsetup.
Lorsque la récupération est terminée, nous sécurisons la partition de la manière suivante :

$ cryptsetup luksFormat -c aes -h sha256 /dev/xvdd1

Cette commande permet de formater la partiton au type LUKS et chiffre en AES avec un algorithme de hashage SHA256. Nous choisissons une phrase de chiffrement.

Une fois la partition chiffrée, nous ouvrons un volume dans notre partition chiffrée :

$ cryptsetup luksOpen /dev/xvdd1 home

Nous la formatons en ext4 :

$ mkfs -t ext4 /dev/mapper/home

Enfin, nous montons la partition sous /mnt :

$ mount -t ext4 /dev/mapper/home /mnt

Nous y créons ensuite un fichier texte. La suite de cette partie, qui est d'échanger les cartes SD, n'est pas réalisable dans notre cas.

TP sysres IMA5sc 2018/2019 G7

2018-12-17T17:58:21Z

Mcreteur : /* 5. Tests d'intrusion */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1500px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves

ZONES INVERSES A FAIRE

===DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/3.0/mods-enabled/eap :
default_eap_type = peap

- /etc/freeradius/3.0/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

== 5. Tests d'intrusion ==
===Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlp2s0

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px]]

===Cassage de clé WEP===

Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlx40a5ef012c92

Nous affichons ensuite tout les point d'accés environnants protégés en WEP en utilisant la commande :

$ airodump-ng --encrypt wep wlan0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng --channel 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlan0mon

En parallèle, on simule une connexion au point d'accès pour récupérer le handshake :
$ aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:50:56 wlan0mon

On réalise le cassage :
$ aircrack-ng ./path_to_folder/cracotte07.cap

[[Fichier:cassagewep07.png|600px]]

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On monte le RAID dans notre VM :
mount /dev/md0 /mnt

On créé un fichier sur le RAID pour qu'il contienne des données. On ferme la VM et on lui retire la partition xvdc3 dans sa config.
On relance la VM. Puis on essaye de remonter le RAID :
En voulant remonter /dev/md0, un message nous indique que md0 n'existe pas. On lance alors la commande :
cat /proc/mdstat
Et on s'aperçoit que notre RAID est toujours présent, cette fois n'ayant plus que deux disques, mais apparaît sous le nom md127. On monte alors ce derrnier :
mount /dev/md127 /mnt
On retrouve alors bien le fichier créé initialement sur notre RAID. Lors de sa création, le fichier a été copié sur les 3 disques par le RAID. Ainsi, lorsque que nous avons supprimé un disque, cela n'a pas eu d'impact sur nos données.

[[Fichier:Raidhercule.png|600px]]

===6.1 Cryptage de données===

Dans notre cas, nous n'utilisons pas une carte SD. Nous créons cependant une partition de 1 Giga sur cordouan sur laquelle on travaillera :

$ lvcreate -L 1G -n /dev/virtual/hercule-crypt -v

Une fois cette action réalisée, et la partition intégrée au fichier de configuration de la machine virtuelle sous forme de volume, de nom xvdd1, nous récupérons les paquets lvm2 et cryptsetup.
Lorsque la récupération est terminée, nous sécurisons la partition de la manière suivante :

$ cryptsetup luksFormat -c aes -h sha256 /dev/xvdd1

Cette commande permet de formater la partiton au type LUKS et chiffre en AES avec un algorithme de hashage SHA256. Nous choisissons une phrase de chiffrement.

Une fois la partition chiffrée, nous ouvrons un volume dans notre partition chiffrée :

$ cryptsetup luksOpen /dev/xvdd1 home

Nous la formatons en ext4 :

$ mkfs -t ext4 /dev/mapper/home

Enfin, nous montons la partition sous /mnt :

$ mount -t ext4 /dev/mapper/home /mnt

Nous y créeons ensuite un fichier texte.

Fichier:Cassagewep07.png

2018-12-17T17:57:10Z

Mcreteur :

TP sysres IMA5sc 2018/2019 G7

2018-12-17T17:27:15Z

Mcreteur : /* 5. Tests d'intrusion */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1500px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves

ZONES INVERSES A FAIRE

===DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/3.0/mods-enabled/eap :
default_eap_type = peap

- /etc/freeradius/3.0/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

== 5. Tests d'intrusion ==
===Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlp2s0

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px]]

===Cassage de clé WEP===

Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi pour la mettre en mode moniteur:

$ airmon-ng start wlx40a5ef012c92

Nous affichons ensuite tout les point d'accés environnants protégés en WEP en utilisant la commande :

$ airodump-ng --encrypt wep wlan0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng --channel 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlan0mon

En parallèle, on simule une connexion au point d'accès pour récupérer le handshake :
$ aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:50:56 wlan0mon

On réalise le cassage :
$ aircrack-ng ./path_to_folder/cracotte07.cap

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On monte le RAID dans notre VM :
mount /dev/md0 /mnt

On créé un fichier sur le RAID pour qu'il contienne des données. On ferme la VM et on lui retire la partition xvdc3 dans sa config.
On relance la VM. Puis on essaye de remonter le RAID :
En voulant remonter /dev/md0, un message nous indique que md0 n'existe pas. On lance alors la commande :
cat /proc/mdstat
Et on s'aperçoit que notre RAID est toujours présent, cette fois n'ayant plus que deux disques, mais apparaît sous le nom md127. On monte alors ce derrnier :
mount /dev/md127 /mnt
On retrouve alors bien le fichier créé initialement sur notre RAID. Lors de sa création, le fichier a été copié sur les 3 disques par le RAID. Ainsi, lorsque que nous avons supprimé un disque, cela n'a pas eu d'impact sur nos données.

[[Fichier:Raidhercule.png|600px]]

===6.1 Cryptage de données===

Dans notre cas, nous n'utilisons pas une carte SD. Nous créons cependant une partition de 1 Giga sur cordouan sur laquelle on travaillera :

$ lvcreate -L 1G -n /dev/virtual/hercule-crypt -v

Une fois cette action réalisée, et la partition intégrée au fichier de configuration de la machine virtuelle sous forme de volume, de nom xvdd1, nous récupérons les paquets lvm2 et cryptsetup.
Lorsque la récupération est terminée, nous sécurisons la partition de la manière suivante :

$ cryptsetup luksFormat -c aes -h sha256 /dev/xvdd1

Cette commande permet de formater la partiton au type LUKS et chiffre en AES avec un algorithme de hashage SHA256. Nous choisissons une phrase de chiffrement.

Une fois la partition chiffrée, nous ouvrons un volume dans notre partition chiffrée :

$ cryptsetup luksOpen /dev/xvdd1 home

Nous la formatons en ext4 :

$ mkfs -t ext4 /dev/mapper/home

Enfin, nous montons la partition sous /mnt :

$ mount -t ext4 /dev/mapper/home /mnt

Nous y créeons ensuite un fichier texte.

TP sysres IMA5sc 2018/2019 G7

2018-12-17T16:06:19Z

Mcreteur : /* 5. Tests d'intrusion */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1500px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves

ZONES INVERSES A FAIRE

===DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/3.0/mods-enabled/eap :
default_eap_type = peap

- /etc/freeradius/3.0/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

== 5. Tests d'intrusion ==
===Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi (wlp2s0) :

$ airmon-ng start wlp2s0mon

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px]]

===Cassage de clé WEP===

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On monte le RAID dans notre VM :
mount /dev/md0 /mnt

On créé un fichier sur le RAID pour qu'il contienne des données. On ferme la VM et on lui retire la partition xvdc3 dans sa config.
On relance la VM. Puis on essaye de remonter le RAID :
En voulant remonter /dev/md0, un message nous indique que md0 n'existe pas. On lance alors la commande :
cat /proc/mdstat
Et on s'aperçoit que notre RAID est toujours présent, cette fois n'ayant plus que deux disques, mais apparaît sous le nom md127. On monte alors ce derrnier :
mount /dev/md127 /mnt
On retrouve alors bien le fichier créé initialement sur notre RAID. Lors de sa création, le fichier a été copié sur les 3 disques par le RAID. Ainsi, lorsque que nous avons supprimé un disque, cela n'a pas eu d'impact sur nos données.

[[Fichier:Raidhercule.png|600px]]

TP sysres IMA5sc 2018/2019 G7

2018-12-17T16:05:16Z

Mcreteur : /* Serveur Freeradius */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1500px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves

ZONES INVERSES A FAIRE

===DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/3.0/mods-enabled/eap :
default_eap_type = peap

- /etc/freeradius/3.0/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

== 5. Tests d'intrusion ==
===Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi (wlp2s0) :

$ airmon-ng start wlp2s0mon

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px]]

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On monte le RAID dans notre VM :
mount /dev/md0 /mnt

On créé un fichier sur le RAID pour qu'il contienne des données. On ferme la VM et on lui retire la partition xvdc3 dans sa config.
On relance la VM. Puis on essaye de remonter le RAID :
En voulant remonter /dev/md0, un message nous indique que md0 n'existe pas. On lance alors la commande :
cat /proc/mdstat
Et on s'aperçoit que notre RAID est toujours présent, cette fois n'ayant plus que deux disques, mais apparaît sous le nom md127. On monte alors ce derrnier :
mount /dev/md127 /mnt
On retrouve alors bien le fichier créé initialement sur notre RAID. Lors de sa création, le fichier a été copié sur les 3 disques par le RAID. Ainsi, lorsque que nous avons supprimé un disque, cela n'a pas eu d'impact sur nos données.

[[Fichier:Raidhercule.png|600px]]

TP sysres IMA5sc 2018/2019 G7

2018-12-17T15:50:04Z

Mcreteur : /* 6. Réalisation */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1500px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves

ZONES INVERSES A FAIRE

===DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/mods-enabled/eap.conf :
default_eap_type = peap

- /etc/freeradius/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

== 5. Tests d'intrusion ==
===Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi (wlp2s0) :

$ airmon-ng start wlp2s0mon

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px]]

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On monte le RAID dans notre VM :
mount /dev/md0 /mnt

On créé un fichier sur le RAID pour qu'il contienne des données. On ferme la VM et on lui retire la partition xvdc3 dans sa config.
On relance la VM. Puis on essaye de remonter le RAID :
En voulant remonter /dev/md0, un message nous indique que md0 n'existe pas. On lance alors la commande :
cat /proc/mdstat
Et on s'aperçoit que notre RAID est toujours présent, cette fois n'ayant plus que deux disques, mais apparaît sous le nom md127. On monte alors ce derrnier :
mount /dev/md127 /mnt
On retrouve alors bien le fichier créé initialement sur notre RAID. Lors de sa création, le fichier a été copié sur les 3 disques par le RAID. Ainsi, lorsque que nous avons supprimé un disque, cela n'a pas eu d'impact sur nos données.

[[Fichier:Raidhercule.png|600px]]

Fichier:Raidhercule.png

2018-12-17T15:49:21Z

Mcreteur :

TP sysres IMA5sc 2018/2019 G7

2018-12-17T15:47:25Z

Mcreteur : /* 6. Réalisation */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1500px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves

ZONES INVERSES A FAIRE

===DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/mods-enabled/eap.conf :
default_eap_type = peap

- /etc/freeradius/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

== 5. Tests d'intrusion ==
===Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi (wlp2s0) :

$ airmon-ng start wlp2s0mon

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px]]

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On monte le RAID dans notre VM :
mount /dev/md0 /mnt

On créé un fichier sur le RAID pour qu'il contienne des données. On ferme la VM et on lui retire la partition xvdc3 dans sa config.
On relance la VM. Puis on essaye de remonter le RAID :
En voulant remonter /dev/md0, un message nous indique que md0 n'existe pas. On lance alors la commande :
cat /proc/mdstat
Et on s'aperçoit que notre RAID est toujours présent, cette fois n'ayant plus que deux disques, mais apparaît sous le nom md127. On monte alors ce derrnier :
mount /dev/md127 /mnt
On retrouve alors bien le fichier créé initialement sur notre RAID. Lors de sa création, le fichier a été copié sur les 3 disques par le RAID. Ainsi, lorsque que nous avons supprimé un disque, cela n'a pas eu d'impact sur nos données.

TP sysres IMA5sc 2018/2019 G7

2018-12-17T15:12:51Z

Mcreteur : /* 6. Réalisation */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1500px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves

ZONES INVERSES A FAIRE

===DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/mods-enabled/eap.conf :
default_eap_type = peap

- /etc/freeradius/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

== 5. Tests d'intrusion ==
===Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi (wlp2s0) :

$ airmon-ng start wlp2s0mon

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px]]

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

Installation du paquetage mdadm pour réaliser le RAID5 logiciel :
apt-get install mdadm

Création du RAID5 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdc1 /dev/xvdc2 /dev/xvdc3

On formate le RAID créé :
mkfs -t ext4 /dev/md0

On le monte :

TP sysres IMA5sc 2018/2019 G7

2018-12-17T14:54:55Z

Mcreteur : /* 6. Réalisation */

= Wiki de TP =

=TP GIS=

==Conteneurs "à la main"==

===Mise en place des conteneurs===

*'''Création d'une partition''':
dd if=/dev/zero of=/disk1 bs=1024K count=10240

*'''Formatage''' :
mtfs.etx4 /disk1

*'''Montage de la partition''':
mount /disk1 /mnt

*'''Installation d'un système Debian''':
debootstrap --include=apache2,nano stable /mnt

*'''Préparation du montage du pseudo système de fichier /proc''':
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

*''' Démontage ''':
umount /mnt

*'''Copie en 2 exemplaires''':
cp /disk1 /disk2
cp /disk1 /disk3

*'''Montage des 3 partitions :'''
mount -oloop /disk1 /mnt/dsk1
mount -oloop /disk2 /mnt/dsk2
mount -oloop /disk3 /mnt/dsk3

*'''Création du processus isolé par unshare''':
unshare -p -f -m -n -u chroot /mnt/dsk1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -p -f -m -n -u chroot /mnt/dsk3 /bin/sh -c "mount /proc ; /bin/bash"

===Configuration réseau===
*'''Création d'un commutateur logiciel''':
ip link add mehcret2 type bridge

*'''Création des interfaces virtuelles:'''
ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

*'''Ajout d'interfaces dans le commutateur :'''
ip link set vif1 master mehcret2
ip link set vif2 master mehcret2
ip link set vif3 master mehcret2
ip link set vif4 master bridge

*'''Activation des interfaces''':
ip link set eth0 up
ip link set eth1 up

*'''Récupération du PID des conteneurs :'''
ps auxwww | grep unshare

*'''Ajout des interfaces dans les conteneurs :'''
ip link set eth0@vif2 netns /proc/19382/ns/net name eth0 (dsk1)
ip link set eth0@vif1 netns /proc/19377/ns/net name eth0 (dsk2)
ip link set eth1@vif4 netns /proc/19377/ns/net name eth1 (dsk2)
ip link set eth0@vif3 netns /proc/19396/ns/net name eth0 (dsk3)

*'''Activation du pont:'''
ip address add dev mehcret2 192.168.60.0/24

*'''Attribution des adresses:'''
ip address add dev eth0 192.168.60.51/24 (dsk1)
ip address add dev eth0 192.168.60.52/24 (dsk2)
ip address add dev eth0 192.168.60.53/24 (dsk3)
ip address add dev eth1 172.26.145.67/24 (dsk2)
ip route add default via 172.26.145.254 (dsk2)

*'''Activation :'''
ip link set eth0 up
ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up
ip link set mehcret2 up

On peut désormais pinger entre les différents conteneurs.

===Configuration des serveurs Web===

Nous devons maintenant mettre en place les serveurs apache.

Dans un premier temps, on créé les sous-domaines dont nous avons besoin. Dans les enregistrements DNS du domaine '''plil.space''', on ajoute les enregistrements suivants :

- mndtMehcret A 172.26.145.67 (mndtMehcret sera le serveur mandataire. On le fait pointer sur l'adresse eth1 du conteneur 2)

- web1Mehcret CNAME mndtMehcret (Serveur web du conteneur 1)

- web2Mehcret CNAME mndtMhecret (Serveur web du conteneur 3)

On configure ensuite les serveurs Apache. On attribue au premier serveur sur le conteneur 1 la configuration suivante dans le répertoire /etc/apache2/sites-available/ :

<VirtualHost *:80>
ServerName web1mehcret.plil.space
Options Indexes FollowSymLinks
DocumentRoot /var/www/html/web1mehcret/
</VirtualHost>

On fait de même dans le conteneur 3 pour le serveur 2 en mettant les ServerName et Document root associés.
On écrit ensuite une page HTML basique dans les dossiers /var/www/html/web1mehcret/ et /var/www/html/web2mehcret/ afin de reconnaître notre serveur web.

Il faut maintenant mettre en place le reverse proxy.
Dans le conteneur 2, connectée à la fois à eth0 et eth1, nous mettons en place la configuration suivante :

<VirtualHost *:80>
ServerName mndtMehcret.plil.space
ProxyPass "/web1" "http://192.168.60.51/"
ProxyPassReverse "/web1" "http://192.168.60.51/"
ProxyPass "/web2" "http://"http://192.168.60.53/"
ProxyPassReverse "/web2" "http://192.168.60.53/"
</VirtualHost>

Les lignes ProxyPass et ProxyPassReverse permettent alors la redirection sur les serveurs web du conteneur 1 et 3.

Après avoir configuré les différents serveurs Apache, il faut redémarrer les services sur chaque conteneur :

$ service apache2 restart

Pour utiliser apache en mode reverse proxy, on execute la commande :

$ a2enmod proxy proxy_http

11h25 : Serveurs Web unshare OK

==Conteneurs Docker==

Avant de lancer un conteneur, il faut modifier le fichier /etc/default/docker et commenter la ligne contenant iptables.
Nous exécutons ensuite la commande :
$ iptables-save
Puis on redémarre le service Docker :
$ service docker restart

Sans les commandes réalisées précédemment, nous n'avions pas accès au réseau dans les conteneurs.

Nous pouvons maintenant lancer un conteneur basé sur l'image officielle de debian :
$ docker run -i -t debian

Dans le conteneur, nous ajoutons le proxy de l'école :
$ export http_proxy=http://proxy.polytech-lille.fr:3128/

Nous pouvons maintenant utiliser le gestionnaire de paquets apt afin d'installer apache2 et un éditeur de texte:
$ apt-get update
$ apt-get install apache2, nano, vim

On sauvegarde ensuite le conteneur pour pouvoir le lancer plus tard en 3 exemplaires :

$ docker commit [IDduConteneur] mehcret

On créé un réseau Docker pour isoler nos conteneurs ensemble :

$ docker network create --driver bridge mehcretnetwork

Nous lançons ensuite 3 conteneurs sur le réseau précédemment créé en liant le port 80 du conteneur 3 (qui jouera le rôle de reverse proxy) au port 80 de la machine :

$ docker run -i --network mehcretnetwork --name mehcret1 mehcret
$ docker run -i --network mehcretnetwork --name mehcret2 mehcret
$ docker run -i --network mehcretnetwork --name mehcret3 -p 80:80 mehcret

Nous créons un nouveau sous domaine, dockerMehcret.plil.space pointant sur l'adresse IP de notre bridge en ajoutant un enregistrement de type A.
Finalement, on configure les différents serveurs Apache comme nous l'avions fait dans la partie précédente.

10h30 Serveurs Web (docker) OK

=TP PRA=

Cet atelier consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous aurons à installer une machine virtuelle Xen ainsi qu’à implanter un auto-commutateur téléphonique logiciel. Enfin la mise en place d’un réseau Wifi sécurisé et d’un site web sécurisé nous permettra de mettre en pratiques nos connaissances en la matière.

==Tâche 5 : Câblage, connexion SR52, cordouan==

===Connexion des routeurs au réseau de l'école===

*'''Connexion SR52 - Routeur ISR4221 (E306)'''

Dans le local SR52, on branche un câble du port 21 du routeur jusqu'au port K-16 du commutateur qui est relié à la prise murale qui se situe au dessus de cordouan en E306.

Sur le routeur, on passe le port 21 sur le vlan 131 :

config t
int gi1/0/21
switchport access vlan 131
write

En E306, on relie le port Gigabit 0/0/0 du routeur ISR4221 à la prise murale SR52.3-K16.

Les LEDs passent alors au vert et on observe que le port 21 du routeur en SR52 est bien connecté :

<gallery mode="nolines" widths=500px heights=400px>

File:TableVlansInterfacesSR52.jpg

File:LedSR52.jpg

</gallery>

*'''Connexion SR52 - Routeur Catalyst 3560 (E304)'''

En E304, on remarque une fibre libre de code couleur Blanc-Noir, on retrouve cette même fibre connectée au routeur en SR52 sur une interface 10Gb et déjà configurée sur le bon Vlan. On branche alors cette fibre sur la première interface 10 Gb du routeur Catalyst 3560 en E304 en accord avec le groupe configurant ce routeur. Le routeur de la E304 est désormais connecté au réseau de l'école.

===Connexion des commutateurs aux routeurs===

*'''Connexion Routeur Catalyst 3560 - Commutateur 4006 (E304)'''

Le routeur utilisé en E304 permettant la communication 10Gb, on relie le commutateur au routeur par 10 câbles afin de profiter au maximum des possibilités offertes par le Catalyst 3560. Le groupe s'occupant des commutateurs ayant configuré le commutateur de la E304 pour communiquer avec le routeur de cette même salle par les ports 4 à 13, on branche 10 câbles ethernet sur ces ports que l'on relie au routeur sur les ports 1 à 10.

*'''Connexion Routeur ISR 4221 - Commutateur 6000 (E306)'''

Contrairement au routeur utilisé en E304, le routeur en E306 ne permet une communication que Gb. Le commutateur sera donc relié au routeur par un seul câble. En accord avec le groupe configurant le routeur et celui configurant le commutateur, on relie ces derniers par un câble ethernet du port Gigabit 0/0/2 du routeur au port 14 du commutateur.

*'''Connexion Routeur ISR 4221 (E306) - Commutateur 4006 (E304) '''

La connexion entre le routeur et le commutateur doit se faire par fibre étant donné que ces deux appareils se trouvent dans deux salles différentes. On utilise pour cela la fibre disponible de code couleur (A COMPLETER). Du côté de la salle E306, on connecte la fibre à l'interface Gb 0/0/1. En E304, on connecte la fibre sur un port UPLINK du commutateur.

*'''Connexion Commutateur 6000 (E306) - Routeur Catalyst 3560 (E304) '''

La connexion au niveau du routeur ne pouvant se faire ici que par cuivre, nous devons utiliser un convertisseur fibre - cuivre. Pour interconnecter le commutateur 6000 au routeur Catalyst 3560, nous utilisons la fibre disponible de code couleur ORANGE. On connecte alors cette fibre sur le port (A COMPLETER) du commutateur de la E306. De l'autre côté, en E304, on connecte la fibre à un convertisseur puis le convertisseur au port 11 du routeur par un câble ethernet en accord avec le groupe configurant ce routeur.

===Connexions au serveur Cordouan===

Finalement, il faut connecter le serveur Cordouan à notre réseau afin d'avoir du réseau sur nos futures VM.

*'''Connexion Commutateur 6000 (E306) - Serveur Cordouan '''

Le commutateur 6000 se trouvant dans la même salle que le serveur Cordouan, on peut relier ces derniers par cuivre. On relie alors le port 17 au serveur Cordouan par câble ethernet.

*'''Connexion Routeur Catalyst 3560 (E306) - Serveur Cordouan '''

Ces deux appareils se trouvant dans deux salles différentes, la connexion ne peut se faire que par fibre. Cependant, nous ne disposons plus de convertisseur. Nous avons donc relié le serveur Cordouan au routeur de la E306 plutôt qu'au commutateur. Nous avons pour cela utilisé la fibre de code couleur BLEU. Nous connectons d'un côté la fibre au deuxième port Gigabit du routeur 3560, et de l'autre, la fibre au serveur Cordouan.

===Connexion des commutateurs aux points d'accès===

===Schéma résumant le câblage réalisé :===

[[Fichier:ArchitectureMehCret.png|1500px]]

== 2.Installation des systèmes d'exploitation==

===Création de la machine virtuelle===

Création d'une machine virtuelle sur cordouan.insecserv.deule.net :

xen-create-image --hostname=hercule --ip=193.48.57.183 --netmask=255.255.255.224 --gateway=193.48.57.160 --dir=/usr/local/xen

Il fois la machine créée, on ajoute le bridge dans la config hercule.cfg

vif = ['ip=193.48.57.183 , mac=#####, bridge=StudentsInfo']
xen create hercule.cfg

On vérifie que la machine est bien créée en s'y connectant :

xl console hercule

Création des partitions logiques sur Cordouan pour la machine virtuelle :
lvcreate -L 10G -n /dev/virtual/hercule-home -v
lvcreate -L 10G -n /dev/virtual/hercule-var -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :
'phy:/dev/virtual/hercule-home,xvdb1,w',
'phy:/dev/virtual/hercule-var,xvdb2,w'

On relance la VM.
On formate les disques créés sur la machine :
mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdb2

Afin de lier le home de notre vm au disque créé précédemment, on modifie le fichier /etc/fstab en y ajoutant la ligne suivante :
/dev/xvdb1 /home ext4 defaults 0 2
Puis on effectue le montage :
mount -a

Pour le var, il faut monter temporairement le disque pour ne pas occulter le repertoire :
mount /dev/xvdb2 /mnt

On déplace ensuite le contenu de var dans le point de montage précédemment créé :
mv /var/* /mnt

Finalement, on ajoute dans le fichier /etc/fstab la ligne suivante pour effectuer le montage permanent :
/dev/xvdb2 /var ext4 defaults 0 2

On applique les modifications :
mount -a

==4.Services internet==

===Serveur DNS===

Achat du domaine hercule.pw sur gandi.

Installation de bind9:

apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :
On créé un fichier de configuration de zone db.hercule.space dans /etc/bind/ avec le contenu suivant :

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hercule.space. root.hercule.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.hercule.space.
IN NS ns6.gandi.net
@ IN A 193.48.57.183
ns IN A 193.48.57.183
www IN A 193.48.57.183

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

zone "hercule.space" {
type master;
file "/etc/bind/db.hercule.space";
allow-transfer {217.70.177.40;};
};

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

Redémarrage du serveur bind9 :
service bind9 restart

Ajout de glue records sur Gandi pour permettre l'association du serveur DNS créé avec notre adresse IP :
name : ns.hercule.space
IP address : 193.48.57.183

Changement du nameserver principal sur Gandi (A FAIRE):
DNS 1 : ns.hercule.space

On laisse ceux de Gandi pour les deux serveurs esclaves

ZONES INVERSES A FAIRE

===DNSSEC===

Dans un premier temps, on active DNSSEC en ajoutant dans le fichier /etc/bind/named la ligne :
dnssec-enable yes;

Création d'un répertoire de nom hercule.space.dnssec pour y générer les clefs

Création de la clef asymétrique de signature de clefs de zone :

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hercule.space
:
Création de la clef asymétrique de la zone pour signer les enregistrements :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hercule.space

On renomme ces clef :
hercule.space-ksk.key
hercule.space-zsk.key

Puis on les inclus dans le fichier /etc/bind/db.hercule.space
$include /etc/bind/hercule.space.dnssec/hercule.space-ksk.key
$include /etc/bind/hercule.space.dnssec/hercule.space-zsk.key

On signe les enregistrements de la zone :
dnssec-signzone -o hercule.space -k hercule.space-ksk ../db.hercule.space hercule.space-zsk

On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed :
file "/etc/bind/db.hercule.space.signed";

On communique les parties publiques de la KSK et ZSK à Gandi dans l'onglet DNSSEC. On n'oublie pas également d'incrémenter le SERIAL dans le fichier db.hercule.space.

===Serveur Apache===

Création du dossier /var/www/www.hercule.pw

*''' Certification SSL :'''

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hercule.pw.key -out hercule.pw.csr

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

*'''Configuration Apache :'''

Configuration du serveur web dans le fichier /etc/apache2/sites-available/hercule.space.conf

<VirtualHost 193.48.57.183:443>
ServerName www.hercule.space
ServerAlias hercule.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.hercule.space.crt
SSLCertificateKeyFile /etc/ssl/private/hercule.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.183:80>
ServerName www.hercule.space
ServerAlias hercule.space
Redirect / https://www.hercule.space
</VirtualHost>

Modification du fichier ports.conf pour que le serveur web écoute sur le port 443 :

Listen 80 443

On active enfin le module SSL, notre site, et on redémarre le service apache :
a2enmod ssl
a2ensite hercule.space.conf
service apache2 restart

===Serveur Freeradius===

Installation de Freeradius sur la vm :
apt-get install freeradius

On ajoute ensuite un utilisateur au serveur freeradius. Pour cela, dans le fichier /etc/freeradius/3.0/users on ajoute :
hercule Cleartext-Password := "glopglop"

Il nous est demandé de configurer le serveur en PEAP-MSCHAPv2. Pour cela, on modifie les fichiers :

- /etc/freeradius/mods-enabled/eap.conf :
default_eap_type = peap

- /etc/freeradius/mods-enabled/mschap :
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On ajoute les points d'accès dans notre configuration de serveur (fichier : /etc/freeradius/3.0/clients.conf) :
client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

client 192.168.0.11/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

On met à jour la configuration :
ldconfig

== 5. Tests d'intrusion ==
===Crackage de clé WPA===

Afin de lancer le crackage de clé WPA sur le point d'accès cracotte07, nous avons besoin du package aircrack-ng que nous installons. Nous affichons ainsi nos interfaces avec la commande :

$ iwconfig

Nous lançons alors airmon-ng avec notre interface wifi (wlp2s0) :

$ airmon-ng start wlp2s0mon

Nous affichons ensuite tout les point d'accés environnants en utilisant la commande :

$ airodump-ng wlp2s0mon

Nous capturons des paquets provenants de cracotte07 que nous enregistrons dans un fichier :

$ airodump-ng -c 9 --bssid 04:DA:d2:9C:50:56 -w ./path_to_folder/cracotte07 wlp2s0mon

Une fois les fichiers générés, nous les transférons sur une ZABETH. Avant de lancer le craquage, nous devons générer un dictionnaire contenant toutes les combinaisons possibles de 8 chiffres. Pour cela, nous réalisons le script bash suivant :

#!/bin/bash
charset=({0..9})
permute(){
(($1 == 0)) && { echo "$2"; return; }
for char in "${charset[@]}"
do
permute "$((${1} - 1 ))" "$2$char"
done
}
permute "$1"

Que nous laçons en exécutant :

$ ./comb.sh 8 >> dictionnaire.txt

Le crack est effectué en lançant la commande :

$ aircrack-ng -a2 -b 04:DA:D2:9C:50:56 -w /path_to_file/dictionnaire.txt /path_to_file/*.cap

Nous récupérons la clé après quelques heures de calcul :

[[Fichier:Crack groupe7.png|600px]]

== 6. Réalisation ==

===6.1 Sécurisation de données===

Création de trois partitions LVM de 1Go sur Cordouan :
lvcreate -L 1G -n /dev/virtual/hercule1 -v
lvcreate -L 1G -n /dev/virtual/hercule2 -v
lvcreate -L 1G -n /dev/virtual/hercule3 -v

Modification du fichier de configuration de la machine virtuelle pour prendre en compte ces volumes créés. Ajout des lignes :

'phy:/dev/virtual/hercule1,xvdc1,w',
'phy:/dev/virtual/hercule2,xvdc2,w',
'phy:/dev/virtual/hercule3,xvdc3,w'

On relance la VM. On formate les disques créés sur la machine :

mkfs -t ext4 /dev/xvdc1
mkfs -t ext4 /dev/xvdc2
mkfs -t ext4 /dev/xvdc3

Afin de lier les dossiers /hercule1 /hercule2 /hercule3 de notre vm au disques créé précédemment, on modifie le fichier /etc/fstab en y ajoutant les lignes suivantes :

/dev/xvdc1 /hercule1 ext4 defaults 0 2
/dev/xvdc2 /hercule2 ext4 defaults 0 2
/dev/xvdc3 /hercule3 ext4 defaults 0 2

Puis on effectue le montage :

mount -a