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

Projets IMA5 2016/2017

2017-02-26T11:00:32Z

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

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>

<tr>
<td>[[P1 Automatisation de tests de validation d'un logiciel embarqué]]</td>
<td> Thomas ROJ / Maxime SZWECHOWIEZ </td>
<td> Thomas VANTROYS (Ecole)</td>
<td> 11/12/2016, 21:47 </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P3 Chaise vibrante pour enfant sourd]]</td>
<td> Geoffrey Piekacz </td>
<td> Rodolphe Astori / Alexandre Boé / Thomas Vantroys </td>
<td> 13/12/2016, 15:36</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P5 Réseau de capteurs sur smartphone]]</td>
<td> Léo MAZIER </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> [[Fichier:MazierLéo_PFE.pdf‎]]</td>
<td> </td>
</tr>
<tr>
<td>[[P7 Régulation temps réel sur réseau sans fil ]]</td>
<td> Morgan OBEISSART / Vincent ROBIC </td>
<td> Alexandre BOE / Thomas VANTROYS </td>
<td> 12/12/2016, 23:26</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P14 Conversion DC-DC à liaison AC et circuit L-C-L]]</td>
<td>Nicolas WEGRZYN</td>
<td>Philippe DELARUE</td>
<td>[[Fichier:Rapport_intermédiaire_PFE_Wegrzyn_Nicolas.pdf]],13/12/2016, 00:28</td>
<td></td>
<td></td>
</tr>
<tr>
<td>[[P15 Entreprise : Développement d'une application iOS et Android ]]</td>
<td> Loïc DELECROIX / Julien JOIGNAUX </td>
<td> Thomas VANTROYS (Ecole) / Béatrice CADET (entreprise) </td>
<td> 13/12/2016, 09:13</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P16 Réaliser deux trackers GPS permettant de suivre à distance le trajet d'un coureur ]]</td>
<td> Valentin Taffin / Alexandre Cuadros </td>
<td> Thomas Vantroys (Ecole) / Alexandre Boé (Ecole) </td>
<td> [[Fichier:Rapport_PFE_présoutenance_cuadros_taffin.pdf]], 13/12/2016, 10:38</td>
<td> [[Fichier:Rapport_PFE_Cuadros_Taffin.pdf]]</td>
<td> </td>
</tr>
<tr>
<td>[[P17 Sécurité de l'internet des objets ]]</td>
<td> Jérémie Denéchaud </td>
<td> Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td> </td>
<td> [[Fichier:Denechaud_Rapport.pdf]]</td>
<td> </td>
</tr>
<tr>
<td>[[P19 Relai Ethernet Lora ]]</td>
<td> Cong CHEN / Sonia NDUWAYO </td>
<td> Xavier Redon </td>
<td> 13/12/2016, 13:26</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P20 Conception d'un périphérique USB de type "gadget"]]</td>
<td> Florian Giovannangeli </td>
<td> Xavier Redon (Ecole) </td>
<td> 13/12/2016, 09:29</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P22 Nuage pour sites Web]]</td>
<td> Guillaume VILLEMONT </td>
<td> Xavier Redon (Ecole) </td>
<td> </td>
<td> [[Fichier:Rapport_PFE_final_GuillaumeVILLEMONT.pdf]] </td>
<td> </td>
</tr>
<tr>
<td>[[P23 Poste ébavurage de pièces plastiques ]]</td>
<td> Corentin CASIER / Jordan RAZAFINDRAIBE </td>
<td> Blaise Conrard (Ecole) / L. HAAG (Entreprise) / R. DAVID (Entreprise) / B. MASSART (Entreprise) </td>
<td> 12/12/2016, 23:31</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P24 Contrôle qualité de la production de pièces plastiques ]]</td>
<td> Alex JULITA / Matthier HERWEGH </td>
<td> Blaise Conrard (Ecole) / L. HAAG (Entreprise) / R. DAVID (Entreprise) / B. MASSART (Entreprise) </td>
<td> 13/12/2016, 12:20 </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P25 Supervision calculateur embarqué sur camion ]]</td>
<td> Alexandre DESCAMD / Pierre MICHEL </td>
<td> Thomas Vantroys (Ecole) / R. DAVID (Entreprise) / JF. DUHAUTOIS (Entreprise) </td>
<td>13/12/2016, 08:23 </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P31 Partition HTTP/TLS pour Pepin]]</td>
<td> Mageshwaran SEKAR </td>
<td> Julien IGUCHI-CARTIGNY</td>
<td> [[Fichier:Rapport mi-projet SEKAR.pdf]] 13/12/2016, 08:14</td>
<td> [[Fichier:Rapport_PFE_2017_SEKAR.pdf]]</td>
<td> </td>
</tr>
<tr>
<td>[[P39 Ajouter de nouvelles interactions à la solution Tezeos ]]</td>
<td> Nathan RICHEZ </td>
<td> Samuel Tranchet (Entreprise) / Thomas Vantroys (Ecole) </td>
<td> 13/12/2016, 10:30</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P42 Dispositif à retour tactile ]]</td>
<td> Pierre FITOUSSI </td>
<td> Laurent GRISONI </td>
<td> 13/12/2016, 12:23</td>
<td> [[Fichier:Rapport_fitoussi.pdf]]</td>
<td> </td>
</tr>
<tr>
<td>[[P44 Identification d'un robot mobile ]]</td>
<td> Michel MIKHAEL </td>
<td> Midzodzi PEKPE </td>
<td> 13/12/2016, 08:58 </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P47 Développement d'une interface cerveau-ordinateur ]]</td>
<td> Victor CHARNET </td>
<td> C. Lecocq (Ecole) F. Cabestaing (Labo) A. Duprès (Labo)</td>
<td> [[Fichier:Rapport_Decembre_BCI_Charnet.pdf]],13/12/2016, 08:50 </td>
<td>[[Fichier:Rapport_Final_Fevrier_BCI_Charnet.pdf]] </td>
<td> </td>
</tr>
<tr>
<td>[[P52 Application mobile musicale]]</td>
<td> Julien Bielle/Romain Ruet </td>
<td> Thomas Vantroys (Ecole) </td>
<td>13/12/2016, 11:09 </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P54 Robot assisté par vision pour le tri de pièces métalliques]]</td>
<td> Julian BONVILLE </td>
<td> Rochdi MERZOUKI (Ecole) </td>
<td> 13/12/2016, 08:35</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P55 DiabetGuard ]]</td>
<td> Martin CLAVERIE </td>
<td> Rochdi MERZOUKI (Ecole) / Guillaume DEWAENE (Entreprise)</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P56 Robot testeur de club de golf]]</td>
<td> Joshua LETELLIER </td>
<td> Rochdi MERZOUKI (Ecole) / Guillaume DEWAELE (Entreprise) </td>
<td> 13/12/2016, 08:06</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P57 Robotisation d'un poste de production de pièces à base de fil métallique ]]</td>
<td> Audrey AFFOYON </td>
<td> Blaise CONRARD (Ecole) / Laurent HAAG (Projet CENTAURE) / Antoine HONORE (Entreprise) </td>
<td> [[Fichier:Affoyon_rapport_p57.pdf]], 13/12/2016, 10:34</td>
<td> [[Fichier:affoyon_Rapport_P57.pdf‎]] </td>
<td> </td>
</tr>
<tr>
<td>[[P59 Popsell : application mobile]]</td>
<td> Quentin GRUSON </td>
<td> Thomas VANTROYS (Ecole) / François Vandeplanque (Popsell) </td>
<td> 12/12/2016, 22:36</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P61 Jeux d'aventure grandeur nature ]]</td>
<td> MAIA Stéphane / LENTIEUL Romuald </td>
<td> GAPAS / Thomas Vantroys (Ecole) </td>
<td> 13/12/2016, 00:51</td>
<td> envoyé le 25/02</td>
<td> rendez-vous pris le 23/02</td>
</tr>
<tr>
<td>[[P64 Sécurité de l'IOT ]]</td>
<td> Cédric DUVAL </td>
<td> Thomas Vantroys (Ecole) / Alexandre Boé (Ecole)</td>
<td>[[Fichier:Rapport P64 Cédric DUVAL.pdf]], 13/12/2016, 11:29 </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P66 Rugby ]]</td>
<td> Antonin Claus </td>
<td> Rodolphe Astori / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td> </td>
<td> [[Fichier:P66-Rugby Antonin Claus.pdf]] </td>
<td> </td>
</tr>

</table>

== Matériel nécessaires ==

<table border="1">
<tr>
<th>Projet</th>
<th>Matériel</th>
</tr>
<tr>
<td>P15</td>
<td> 2 téléphones Android (reçus le 30 septembre. Une boite complète + 1 boite sans câble de connexion) </td>
</tr>
<tr>
<td>P16</td>
<td> Arduino MegaADK </td>
</tr>
<tr>
<td>P52</td>
<td> 2 téléphones Android (reçus le 5 octobre. Deux boites complètes) </td>
</tr>
<tr>
<td>P55</td>
<td> 1 téléphone Android (G4C) reçu le 19/01/2017 
</tr>
<tr>
<td>P61</td>
<td> une tablette Android reçu le 10/10/2016 1 Raspberry pi (+dongle Wifi) reçu le 10/10/2016
 9 Raspberry pi (+dongle Wifi) 8 Haut-Parleurs simples 8 clés Bluetooth</td>
</tr>

</table>

Gant de Boxe connecté

2017-01-24T16:55:00Z

Rlentieu : /* Fichiers rendus */

=Présentation du sujet =

==Contexte==
De nos jours, nous vivons entourés de plus en plus d'objets connectés y compris dans le domaine sportif afin d'assister (ou de juger/arbitrer).
Dans le cadre du module d'Internet des Objets, nous avons choisi de réaliser un prototype de gant de boxe connecté. Ce prototype permettra au boxeur et à son équipe de connaître le ratio de coups qui auront atteint leur cible.

==Description du projet==
Le gant utilisé contiendra un (ou plusieurs) capteur de pression placé sur la surface de frappe, ainsi qu'un accéléromètre. Le premier nous permettra de compter le nombre de coups atteints et le second le nombre de coups tentés.
Enfin nous utiliserons un arduino afin de communiquer en BLE (Bluetooth Low Energy) avec une application Android qui affichera les résultats.

=Matériel utilisé=
Par gant:

*Accéléromètre [reçu]
*Capteurs de pression flexibles carrés (x4) [reçus]
*RFduino [reçu]
*Batterie USB [reçu]

=Suivi de réalisation=
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/01)
| Recherche du sujet et du matériel / Mise en place du cahier des charges
|-
! scope="row" | Séance 2 (05/01)
| Début du développement de la partie Arduino et test de récupération de données
|-
! scope="row" | Séance 3 (12/01)
| Développement de l'application Android : réception des données
|-
! scope="row" | Séance 4 (13/01)
| Développement de l'application Android : Traitement des données
|}

==1ère Séance==
Lors de cette séance, nous avons déterminé le fonctionnement de notre projet mais aussi les technologies à utiliser.
Nous avons donc commencé par rechercher les différentes composants nécessaires à notre projet. Nous avons aussi rechercher certaines informations quand au développement de l'application.

De plus, une fois les éléments reçus, nous avons réalisé le circuit.

[[Fichier:Circuit_IOT.jpg|center|250px]]

==2ème Séance==

Pendant cette séance nous avons commencé à programmer la partie arduino en ayant au préalable importé les différentes librairies du RFduino. Nous nous sommes renseigné sur les différentes frameworks existantes pour la programmation de BLE.
Suite à cela, nous avons choisi de faire une application android communiquant en bluetooth. Celle-ci serait d'avantage mobile qu'une application ordinateur et plairait d'avantage à un sportif qui pourrait voir directement ses résultats pendant son entraînement ou à son entraîneur qui transporte plus facilement une tablette qu'un ordinateur.

Lors de cette séance, nous avons également commencé à tester notre matériel avec un programme simple sur Arduino qui nous permet de voir que nous recevons bien les données voulues.

==3ème Séance==
Après avoir réalisé en partie le côté RFduino, nous sommes maintenant passés à la partie Android. Pour cela, nous avons choisi d'utiliser l'IDE Android Studio qui va nous permettre de créer notre application.
Cette application devra donc activer le Bluetooth de la tablette s'il n'est pas activé, scanner les alentours afin de capter l'ID du RFduino puis enfin s'y connecter.
Nous arrivons donc bien à détecter notre RFduino. Il nous reste maintenant à nous y connecter afin de pouvoir recevoir les valeurs des capteurs.
Une fois ces valeurs bien reçues, nous devrons les afficher sur l'application sous forme de tableau.
[[Fichier:AppData.png|center|250px]]

==4ème séance==
Nous avons donc réussi à connecter le RFduino avec l'application. Nous avons donc coder la réception des données du côté de l'application mais aussi le traitement de ces données.
On enregistre les valeurs reçues puis on affiche les données importantes pour un boxeur : le nombre de coups tentés et le nombre de coups touchés.
De plus, nous avons également différencié trois grands types de coups "fréquents" lors d'un match de boxe : le jab, le coup droit et l'uppercut.
Chacun de ces coups suivant principalement un axe différent, il est relativement simple de les différencier.
Ainsi on peut savoir si l'utilisateur différencie ses coups ou s'il reste trop souvent dans la même stratégie.

[[Fichier:AppRes.png|center|250px]]

=Poster=

[[Fichier:Poster.png|center|1500px]]
=Fichiers rendus=
Application Android : [[Fichier:AppGant.zip]]

Code RFduino : [[Fichier:RFduino.zip]]

Fichier:RFduino.zip

2017-01-24T16:54:45Z

Rlentieu :

Gant de Boxe connecté

2017-01-24T16:54:20Z

Rlentieu : /* Fichiers rendus */

Fichier:AppGant.zip

2017-01-24T16:53:49Z

Rlentieu :

Gant de Boxe connecté

2017-01-20T12:56:48Z

Rlentieu :

Fichier:Poster LENTIEUL MAIA.pdf

2017-01-19T11:35:16Z

Rlentieu :

Gant de Boxe connecté

2017-01-18T20:04:20Z

Rlentieu : /* Description du projet */

Gant de Boxe connecté

2017-01-18T20:03:39Z

Rlentieu : /* 1ère Séance */

=Présentation du sujet =

==Contexte==
De nos jours, nous vivons entourés de plus en plus d'objets connectés y compris dans le domaine sportif afin d'assister (ou de juger/arbitrer).
Dans le cadre du module d'Internet des Objets, nous avons choisi de réaliser un prototype de gant de boxe connecté. Ce prototype permettra au boxeur et à son équipe de connaître le ratio de coups qui auront atteint leur cible.

==Description du projet==
Le gant utilisé contiendra un (ou plusieurs) capteur de pression placé sur la surface de frappe, ainsi qu'un accéléromètre. Le premier nous permettra de compter le nombre de coups atteints et le second le nombre de coups tentés.
Enfin nous utiliserons un arduino afin de communiquer en BLE (Bluetooth Low Energy) avec l'ordinateur du coach qui affichera les résultats.

=Matériel utilisé=
Par gant:

*Accéléromètre [reçu]
*Capteurs de pression flexibles carrés (x4) [reçus]
*RFduino [reçu]
*Batterie USB [reçu]

=Suivi de réalisation=
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/01)
| Recherche du sujet et du matériel / Mise en place du cahier des charges
|-
! scope="row" | Séance 2 (05/01)
| Début du développement de la partie Arduino et test de récupération de données
|-
! scope="row" | Séance 3 (12/01)
| Développement de l'application Android : réception des données
|-
! scope="row" | Séance 4 (13/01)
| Développement de l'application Android : Traitement des données
|}

==1ère Séance==
Lors de cette séance, nous avons déterminé le fonctionnement de notre projet mais aussi les technologies à utiliser.
Nous avons donc commencé par rechercher les différentes composants nécessaires à notre projet. Nous avons aussi rechercher certaines informations quand au développement de l'application.

De plus, une fois les éléments reçus, nous avons réalisé le circuit.

[[Fichier:Circuit_IOT.jpg|center|250px]]

==2ème Séance==

Pendant cette séance nous avons commencé à programmer la partie arduino en ayant au préalable importé les différentes librairies du RFduino. Nous nous sommes renseigné sur les différentes frameworks existantes pour la programmation de BLE.
Suite à cela, nous avons choisi de faire une application android communiquant en bluetooth. Celle-ci serait d'avantage mobile qu'une application ordinateur et plairait d'avantage à un sportif qui pourrait voir directement ses résultats pendant son entraînement ou à son entraîneur qui transporte plus facilement une tablette qu'un ordinateur.

Lors de cette séance, nous avons également commencé à tester notre matériel avec un programme simple sur Arduino qui nous permet de voir que nous recevons bien les données voulues.

==3ème Séance==
Après avoir réalisé en partie le côté RFduino, nous sommes maintenant passés à la partie Android. Pour cela, nous avons choisi d'utiliser l'IDE Android Studio qui va nous permettre de créer notre application.
Cette application devra donc activer le Bluetooth de la tablette s'il n'est pas activé, scanner les alentours afin de capter l'ID du RFduino puis enfin s'y connecter.
Nous arrivons donc bien à détecter notre RFduino. Il nous reste maintenant à nous y connecter afin de pouvoir recevoir les valeurs des capteurs.
Une fois ces valeurs bien reçues, nous devrons les afficher sur l'application sous forme de tableau.
[[Fichier:AppData.png|center|250px]]

==4ème séance==
Nous avons donc réussi à connecter le RFduino avec l'application. Nous avons donc coder la réception des données du côté de l'application mais aussi le traitement de ces données.
On enregistre les valeurs reçues puis on affiche les données importantes pour un boxeur : le nombre de coups tentés et le nombre de coups touchés.
De plus, nous avons également différencié trois grands types de coups "fréquents" lors d'un match de boxe : le jab, le coup droit et l'uppercut.
Chacun de ces coups suivant principalement un axe différent, il est relativement simple de les différencier.
Ainsi on peut savoir si l'utilisateur différencie ses coups ou s'il reste trop souvent dans la même stratégie.

[[Fichier:AppRes.png|center|250px]]

=Poster=

Gant de Boxe connecté

2017-01-18T20:03:09Z

Rlentieu : /* 4ème séance */

=Présentation du sujet =

==Contexte==
De nos jours, nous vivons entourés de plus en plus d'objets connectés y compris dans le domaine sportif afin d'assister (ou de juger/arbitrer).
Dans le cadre du module d'Internet des Objets, nous avons choisi de réaliser un prototype de gant de boxe connecté. Ce prototype permettra au boxeur et à son équipe de connaître le ratio de coups qui auront atteint leur cible.

==Description du projet==
Le gant utilisé contiendra un (ou plusieurs) capteur de pression placé sur la surface de frappe, ainsi qu'un accéléromètre. Le premier nous permettra de compter le nombre de coups atteints et le second le nombre de coups tentés.
Enfin nous utiliserons un arduino afin de communiquer en BLE (Bluetooth Low Energy) avec l'ordinateur du coach qui affichera les résultats.

=Matériel utilisé=
Par gant:

*Accéléromètre [reçu]
*Capteurs de pression flexibles carrés (x4) [reçus]
*RFduino [reçu]
*Batterie USB [reçu]

=Suivi de réalisation=
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/01)
| Recherche du sujet et du matériel / Mise en place du cahier des charges
|-
! scope="row" | Séance 2 (05/01)
| Début du développement de la partie Arduino et test de récupération de données
|-
! scope="row" | Séance 3 (12/01)
| Développement de l'application Android : réception des données
|-
! scope="row" | Séance 4 (13/01)
| Développement de l'application Android : Traitement des données
|}

==1ère Séance==
Lors de cette séance, nous avons déterminé le fonctionnement de notre projet mais aussi les technologies à utiliser.
Nous avons donc commencé par rechercher les différentes composants nécessaires à notre projet. Nous avons aussi rechercher certaines informations quand au développement de l'application.

De plus, une fois les éléments reçus, nous avons réalisé le circuit.

[[Fichier:Circuit_IOT.jpg|center|300px]]

==2ème Séance==

Pendant cette séance nous avons commencé à programmer la partie arduino en ayant au préalable importé les différentes librairies du RFduino. Nous nous sommes renseigné sur les différentes frameworks existantes pour la programmation de BLE.
Suite à cela, nous avons choisi de faire une application android communiquant en bluetooth. Celle-ci serait d'avantage mobile qu'une application ordinateur et plairait d'avantage à un sportif qui pourrait voir directement ses résultats pendant son entraînement ou à son entraîneur qui transporte plus facilement une tablette qu'un ordinateur.

Lors de cette séance, nous avons également commencé à tester notre matériel avec un programme simple sur Arduino qui nous permet de voir que nous recevons bien les données voulues.

==3ème Séance==
Après avoir réalisé en partie le côté RFduino, nous sommes maintenant passés à la partie Android. Pour cela, nous avons choisi d'utiliser l'IDE Android Studio qui va nous permettre de créer notre application.
Cette application devra donc activer le Bluetooth de la tablette s'il n'est pas activé, scanner les alentours afin de capter l'ID du RFduino puis enfin s'y connecter.
Nous arrivons donc bien à détecter notre RFduino. Il nous reste maintenant à nous y connecter afin de pouvoir recevoir les valeurs des capteurs.
Une fois ces valeurs bien reçues, nous devrons les afficher sur l'application sous forme de tableau.
[[Fichier:AppData.png|center|250px]]

==4ème séance==
Nous avons donc réussi à connecter le RFduino avec l'application. Nous avons donc coder la réception des données du côté de l'application mais aussi le traitement de ces données.
On enregistre les valeurs reçues puis on affiche les données importantes pour un boxeur : le nombre de coups tentés et le nombre de coups touchés.
De plus, nous avons également différencié trois grands types de coups "fréquents" lors d'un match de boxe : le jab, le coup droit et l'uppercut.
Chacun de ces coups suivant principalement un axe différent, il est relativement simple de les différencier.
Ainsi on peut savoir si l'utilisateur différencie ses coups ou s'il reste trop souvent dans la même stratégie.

[[Fichier:AppRes.png|center|250px]]

=Poster=

Fichier:AppRes.png

2017-01-18T20:02:54Z

Rlentieu :

Gant de Boxe connecté

2017-01-18T20:02:10Z

Rlentieu : /* 3ème Séance */

=Présentation du sujet =

==Contexte==
De nos jours, nous vivons entourés de plus en plus d'objets connectés y compris dans le domaine sportif afin d'assister (ou de juger/arbitrer).
Dans le cadre du module d'Internet des Objets, nous avons choisi de réaliser un prototype de gant de boxe connecté. Ce prototype permettra au boxeur et à son équipe de connaître le ratio de coups qui auront atteint leur cible.

==Description du projet==
Le gant utilisé contiendra un (ou plusieurs) capteur de pression placé sur la surface de frappe, ainsi qu'un accéléromètre. Le premier nous permettra de compter le nombre de coups atteints et le second le nombre de coups tentés.
Enfin nous utiliserons un arduino afin de communiquer en BLE (Bluetooth Low Energy) avec l'ordinateur du coach qui affichera les résultats.

=Matériel utilisé=
Par gant:

*Accéléromètre [reçu]
*Capteurs de pression flexibles carrés (x4) [reçus]
*RFduino [reçu]
*Batterie USB [reçu]

=Suivi de réalisation=
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/01)
| Recherche du sujet et du matériel / Mise en place du cahier des charges
|-
! scope="row" | Séance 2 (05/01)
| Début du développement de la partie Arduino et test de récupération de données
|-
! scope="row" | Séance 3 (12/01)
| Développement de l'application Android : réception des données
|-
! scope="row" | Séance 4 (13/01)
| Développement de l'application Android : Traitement des données
|}

==1ère Séance==
Lors de cette séance, nous avons déterminé le fonctionnement de notre projet mais aussi les technologies à utiliser.
Nous avons donc commencé par rechercher les différentes composants nécessaires à notre projet. Nous avons aussi rechercher certaines informations quand au développement de l'application.

De plus, une fois les éléments reçus, nous avons réalisé le circuit.

[[Fichier:Circuit_IOT.jpg|center|300px]]

==2ème Séance==

Pendant cette séance nous avons commencé à programmer la partie arduino en ayant au préalable importé les différentes librairies du RFduino. Nous nous sommes renseigné sur les différentes frameworks existantes pour la programmation de BLE.
Suite à cela, nous avons choisi de faire une application android communiquant en bluetooth. Celle-ci serait d'avantage mobile qu'une application ordinateur et plairait d'avantage à un sportif qui pourrait voir directement ses résultats pendant son entraînement ou à son entraîneur qui transporte plus facilement une tablette qu'un ordinateur.

Lors de cette séance, nous avons également commencé à tester notre matériel avec un programme simple sur Arduino qui nous permet de voir que nous recevons bien les données voulues.

==3ème Séance==
Après avoir réalisé en partie le côté RFduino, nous sommes maintenant passés à la partie Android. Pour cela, nous avons choisi d'utiliser l'IDE Android Studio qui va nous permettre de créer notre application.
Cette application devra donc activer le Bluetooth de la tablette s'il n'est pas activé, scanner les alentours afin de capter l'ID du RFduino puis enfin s'y connecter.
Nous arrivons donc bien à détecter notre RFduino. Il nous reste maintenant à nous y connecter afin de pouvoir recevoir les valeurs des capteurs.
Une fois ces valeurs bien reçues, nous devrons les afficher sur l'application sous forme de tableau.
[[Fichier:AppData.png|center|250px]]

==4ème séance==
Nous avons donc réussi à connecter le RFduino avec l'application. Nous avons donc coder la réception des données du côté de l'application mais aussi le traitement de ces données.
On enregistre les valeurs reçues puis on affiche les données importantes pour un boxeur : le nombre de coups tentés et le nombre de coups touchés.
De plus, nous avons également différencié trois grands types de coups "fréquents" lors d'un match de boxe : le jab, le coup droit et l'uppercut.
Chacun de ces coups suivant principalement un axe différent, il est relativement simple de les différencier.
Ainsi on peut savoir si l'utilisateur différencie ses coups ou s'il reste trop souvent dans la même stratégie.

=Poster=

Fichier:AppData.png

2017-01-18T20:01:28Z

Rlentieu :

Gant de Boxe connecté

2017-01-18T19:59:23Z

Rlentieu : /* 1ère Séance */

=Présentation du sujet =

==Contexte==
De nos jours, nous vivons entourés de plus en plus d'objets connectés y compris dans le domaine sportif afin d'assister (ou de juger/arbitrer).
Dans le cadre du module d'Internet des Objets, nous avons choisi de réaliser un prototype de gant de boxe connecté. Ce prototype permettra au boxeur et à son équipe de connaître le ratio de coups qui auront atteint leur cible.

==Description du projet==
Le gant utilisé contiendra un (ou plusieurs) capteur de pression placé sur la surface de frappe, ainsi qu'un accéléromètre. Le premier nous permettra de compter le nombre de coups atteints et le second le nombre de coups tentés.
Enfin nous utiliserons un arduino afin de communiquer en BLE (Bluetooth Low Energy) avec l'ordinateur du coach qui affichera les résultats.

=Matériel utilisé=
Par gant:

*Accéléromètre [reçu]
*Capteurs de pression flexibles carrés (x4) [reçus]
*RFduino [reçu]
*Batterie USB [reçu]

=Suivi de réalisation=
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/01)
| Recherche du sujet et du matériel / Mise en place du cahier des charges
|-
! scope="row" | Séance 2 (05/01)
| Début du développement de la partie Arduino et test de récupération de données
|-
! scope="row" | Séance 3 (12/01)
| Développement de l'application Android : réception des données
|-
! scope="row" | Séance 4 (13/01)
| Développement de l'application Android : Traitement des données
|}

==1ère Séance==
Lors de cette séance, nous avons déterminé le fonctionnement de notre projet mais aussi les technologies à utiliser.
Nous avons donc commencé par rechercher les différentes composants nécessaires à notre projet. Nous avons aussi rechercher certaines informations quand au développement de l'application.

De plus, une fois les éléments reçus, nous avons réalisé le circuit.

[[Fichier:Circuit_IOT.jpg|center|300px]]

==2ème Séance==

Pendant cette séance nous avons commencé à programmer la partie arduino en ayant au préalable importé les différentes librairies du RFduino. Nous nous sommes renseigné sur les différentes frameworks existantes pour la programmation de BLE.
Suite à cela, nous avons choisi de faire une application android communiquant en bluetooth. Celle-ci serait d'avantage mobile qu'une application ordinateur et plairait d'avantage à un sportif qui pourrait voir directement ses résultats pendant son entraînement ou à son entraîneur qui transporte plus facilement une tablette qu'un ordinateur.

Lors de cette séance, nous avons également commencé à tester notre matériel avec un programme simple sur Arduino qui nous permet de voir que nous recevons bien les données voulues.

==3ème Séance==
Après avoir réalisé en partie le côté RFduino, nous sommes maintenant passés à la partie Android. Pour cela, nous avons choisi d'utiliser l'IDE Android Studio qui va nous permettre de créer notre application.
Cette application devra donc activer le Bluetooth de la tablette s'il n'est pas activé, scanner les alentours afin de capter l'ID du RFduino puis enfin s'y connecter.
Nous arrivons donc bien à détecter notre RFduino. Il nous reste maintenant à nous y connecter afin de pouvoir recevoir les valeurs des capteurs.
Une fois ces valeurs bien reçues, nous devrons les afficher sur l'application sous forme de tableau ou de graphique.

==4ème séance==
Nous avons donc réussi à connecter le RFduino avec l'application. Nous avons donc coder la réception des données du côté de l'application mais aussi le traitement de ces données.
On enregistre les valeurs reçues puis on affiche les données importantes pour un boxeur : le nombre de coups tentés et le nombre de coups touchés.
De plus, nous avons également différencié trois grands types de coups "fréquents" lors d'un match de boxe : le jab, le coup droit et l'uppercut.
Chacun de ces coups suivant principalement un axe différent, il est relativement simple de les différencier.
Ainsi on peut savoir si l'utilisateur différencie ses coups ou s'il reste trop souvent dans la même stratégie.

=Poster=

Fichier:Circuit IOT.jpg

2017-01-18T19:58:20Z

Rlentieu :

Gant de Boxe connecté

2017-01-18T19:54:56Z

Rlentieu : /* 1ère Séance */

=Présentation du sujet =

==Contexte==
De nos jours, nous vivons entourés de plus en plus d'objets connectés y compris dans le domaine sportif afin d'assister (ou de juger/arbitrer).
Dans le cadre du module d'Internet des Objets, nous avons choisi de réaliser un prototype de gant de boxe connecté. Ce prototype permettra au boxeur et à son équipe de connaître le ratio de coups qui auront atteint leur cible.

==Description du projet==
Le gant utilisé contiendra un (ou plusieurs) capteur de pression placé sur la surface de frappe, ainsi qu'un accéléromètre. Le premier nous permettra de compter le nombre de coups atteints et le second le nombre de coups tentés.
Enfin nous utiliserons un arduino afin de communiquer en BLE (Bluetooth Low Energy) avec l'ordinateur du coach qui affichera les résultats.

=Matériel utilisé=
Par gant:

*Accéléromètre [reçu]
*Capteurs de pression flexibles carrés (x4) [reçus]
*RFduino [reçu]
*Batterie USB [reçu]

=Suivi de réalisation=
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/01)
| Recherche du sujet et du matériel / Mise en place du cahier des charges
|-
! scope="row" | Séance 2 (05/01)
| Début du développement de la partie Arduino et test de récupération de données
|-
! scope="row" | Séance 3 (12/01)
| Développement de l'application Android : réception des données
|-
! scope="row" | Séance 4 (13/01)
| Développement de l'application Android : Traitement des données
|}

==1ère Séance==
Lors de cette séance, nous avons déterminé le fonctionnement de notre projet mais aussi les technologies à utiliser.
Nous avons donc commencé par rechercher les différentes composants nécessaires à notre projet. Nous avons aussi rechercher certaines informations quand au développement de l'application.

De plus, une fois les éléments reçus, nous avons réalisé le circuit.

==2ème Séance==

Pendant cette séance nous avons commencé à programmer la partie arduino en ayant au préalable importé les différentes librairies du RFduino. Nous nous sommes renseigné sur les différentes frameworks existantes pour la programmation de BLE.
Suite à cela, nous avons choisi de faire une application android communiquant en bluetooth. Celle-ci serait d'avantage mobile qu'une application ordinateur et plairait d'avantage à un sportif qui pourrait voir directement ses résultats pendant son entraînement ou à son entraîneur qui transporte plus facilement une tablette qu'un ordinateur.

Lors de cette séance, nous avons également commencé à tester notre matériel avec un programme simple sur Arduino qui nous permet de voir que nous recevons bien les données voulues.

==3ème Séance==
Après avoir réalisé en partie le côté RFduino, nous sommes maintenant passés à la partie Android. Pour cela, nous avons choisi d'utiliser l'IDE Android Studio qui va nous permettre de créer notre application.
Cette application devra donc activer le Bluetooth de la tablette s'il n'est pas activé, scanner les alentours afin de capter l'ID du RFduino puis enfin s'y connecter.
Nous arrivons donc bien à détecter notre RFduino. Il nous reste maintenant à nous y connecter afin de pouvoir recevoir les valeurs des capteurs.
Une fois ces valeurs bien reçues, nous devrons les afficher sur l'application sous forme de tableau ou de graphique.

==4ème séance==
Nous avons donc réussi à connecter le RFduino avec l'application. Nous avons donc coder la réception des données du côté de l'application mais aussi le traitement de ces données.
On enregistre les valeurs reçues puis on affiche les données importantes pour un boxeur : le nombre de coups tentés et le nombre de coups touchés.
De plus, nous avons également différencié trois grands types de coups "fréquents" lors d'un match de boxe : le jab, le coup droit et l'uppercut.
Chacun de ces coups suivant principalement un axe différent, il est relativement simple de les différencier.
Ainsi on peut savoir si l'utilisateur différencie ses coups ou s'il reste trop souvent dans la même stratégie.

=Poster=

Gant de Boxe connecté

2017-01-18T19:54:14Z

Rlentieu : /* Suivi de réalisation */

=Présentation du sujet =

==Contexte==
De nos jours, nous vivons entourés de plus en plus d'objets connectés y compris dans le domaine sportif afin d'assister (ou de juger/arbitrer).
Dans le cadre du module d'Internet des Objets, nous avons choisi de réaliser un prototype de gant de boxe connecté. Ce prototype permettra au boxeur et à son équipe de connaître le ratio de coups qui auront atteint leur cible.

==Description du projet==
Le gant utilisé contiendra un (ou plusieurs) capteur de pression placé sur la surface de frappe, ainsi qu'un accéléromètre. Le premier nous permettra de compter le nombre de coups atteints et le second le nombre de coups tentés.
Enfin nous utiliserons un arduino afin de communiquer en BLE (Bluetooth Low Energy) avec l'ordinateur du coach qui affichera les résultats.

=Matériel utilisé=
Par gant:

*Accéléromètre [reçu]
*Capteurs de pression flexibles carrés (x4) [reçus]
*RFduino [reçu]
*Batterie USB [reçu]

=Suivi de réalisation=
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/01)
| Recherche du sujet et du matériel / Mise en place du cahier des charges
|-
! scope="row" | Séance 2 (05/01)
| Début du développement de la partie Arduino et test de récupération de données
|-
! scope="row" | Séance 3 (12/01)
| Développement de l'application Android : réception des données
|-
! scope="row" | Séance 4 (13/01)
| Développement de l'application Android : Traitement des données
|}

==1ère Séance==
Lors de cette séance, nous avons déterminé le fonctionnement de notre projet mais aussi les technologies à utiliser.
Nous avons donc commencé par rechercher les différentes composants nécessaires à notre projet. Nous avons aussi rechercher certaines informations quand au développement de l'application.

==2ème Séance==

Pendant cette séance nous avons commencé à programmer la partie arduino en ayant au préalable importé les différentes librairies du RFduino. Nous nous sommes renseigné sur les différentes frameworks existantes pour la programmation de BLE.
Suite à cela, nous avons choisi de faire une application android communiquant en bluetooth. Celle-ci serait d'avantage mobile qu'une application ordinateur et plairait d'avantage à un sportif qui pourrait voir directement ses résultats pendant son entraînement ou à son entraîneur qui transporte plus facilement une tablette qu'un ordinateur.

Lors de cette séance, nous avons également commencé à tester notre matériel avec un programme simple sur Arduino qui nous permet de voir que nous recevons bien les données voulues.

==3ème Séance==
Après avoir réalisé en partie le côté RFduino, nous sommes maintenant passés à la partie Android. Pour cela, nous avons choisi d'utiliser l'IDE Android Studio qui va nous permettre de créer notre application.
Cette application devra donc activer le Bluetooth de la tablette s'il n'est pas activé, scanner les alentours afin de capter l'ID du RFduino puis enfin s'y connecter.
Nous arrivons donc bien à détecter notre RFduino. Il nous reste maintenant à nous y connecter afin de pouvoir recevoir les valeurs des capteurs.
Une fois ces valeurs bien reçues, nous devrons les afficher sur l'application sous forme de tableau ou de graphique.

==4ème séance==
Nous avons donc réussi à connecter le RFduino avec l'application. Nous avons donc coder la réception des données du côté de l'application mais aussi le traitement de ces données.
On enregistre les valeurs reçues puis on affiche les données importantes pour un boxeur : le nombre de coups tentés et le nombre de coups touchés.
De plus, nous avons également différencié trois grands types de coups "fréquents" lors d'un match de boxe : le jab, le coup droit et l'uppercut.
Chacun de ces coups suivant principalement un axe différent, il est relativement simple de les différencier.
Ainsi on peut savoir si l'utilisateur différencie ses coups ou s'il reste trop souvent dans la même stratégie.

=Poster=

Gant de Boxe connecté

2017-01-18T19:53:19Z

Rlentieu : /* Matériel utilisé */

=Présentation du sujet =

==Contexte==
De nos jours, nous vivons entourés de plus en plus d'objets connectés y compris dans le domaine sportif afin d'assister (ou de juger/arbitrer).
Dans le cadre du module d'Internet des Objets, nous avons choisi de réaliser un prototype de gant de boxe connecté. Ce prototype permettra au boxeur et à son équipe de connaître le ratio de coups qui auront atteint leur cible.

==Description du projet==
Le gant utilisé contiendra un (ou plusieurs) capteur de pression placé sur la surface de frappe, ainsi qu'un accéléromètre. Le premier nous permettra de compter le nombre de coups atteints et le second le nombre de coups tentés.
Enfin nous utiliserons un arduino afin de communiquer en BLE (Bluetooth Low Energy) avec l'ordinateur du coach qui affichera les résultats.

=Matériel utilisé=
Par gant:

*Accéléromètre [reçu]
*Capteurs de pression flexibles carrés (x4) [reçus]
*RFduino [reçu]
*Batterie USB [reçu]

=Suivi de réalisation=
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/01)
| Recherche du sujet et du matériel / Mise en place du cahier des charges
|-
! scope="row" | Séance 2 (05/01)
| Début du développement de la partie Arduino et test de récupération de données
|-
! scope="row" | Séance 3 (12/01)
| Développement de l'application Android
|-
! scope="row" | Séance 4 (13/01)
|
|}

==1ère Séance==
Lors de cette séance, nous avons déterminé le fonctionnement de notre projet mais aussi les technologies à utiliser.
Nous avons donc commencé par rechercher les différentes composants nécessaires à notre projet. Nous avons aussi rechercher certaines informations quand au développement de l'application.

==2ème Séance==

Pendant cette séance nous avons commencé à programmer la partie arduino en ayant au préalable importé les différentes librairies du RFduino. Nous nous sommes renseigné sur les différentes frameworks existantes pour la programmation de BLE.
Suite à cela, nous avons choisi de faire une application android communiquant en bluetooth. Celle-ci serait d'avantage mobile qu'une application ordinateur et plairait d'avantage à un sportif qui pourrait voir directement ses résultats pendant son entraînement ou à son entraîneur qui transporte plus facilement une tablette qu'un ordinateur.

Lors de cette séance, nous avons également commencé à tester notre matériel avec un programme simple sur Arduino qui nous permet de voir que nous recevons bien les données voulues.

==3ème Séance==
Après avoir réalisé en partie le côté RFduino, nous sommes maintenant passés à la partie Android. Pour cela, nous avons choisi d'utiliser l'IDE Android Studio qui va nous permettre de créer notre application.
Cette application devra donc activer le Bluetooth de la tablette s'il n'est pas activé, scanner les alentours afin de capter l'ID du RFduino puis enfin s'y connecter.
Nous arrivons donc bien à détecter notre RFduino. Il nous reste maintenant à nous y connecter afin de pouvoir recevoir les valeurs des capteurs.
Une fois ces valeurs bien reçues, nous devrons les afficher sur l'application sous forme de tableau ou de graphique.

==4ème séance==
Nous avons donc réussi à connecter le RFduino avec l'application. Nous avons donc coder la réception des données du côté de l'application mais aussi le traitement de ces données.
On enregistre les valeurs reçues puis on affiche les données importantes pour un boxeur : le nombre de coups tentés et le nombre de coups touchés.
De plus, nous avons également différencié trois grands types de coups "fréquents" lors d'un match de boxe : le jab, le coup droit et l'uppercut.
Chacun de ces coups suivant principalement un axe différent, il est relativement simple de les différencier.
Ainsi on peut savoir si l'utilisateur différencie ses coups ou s'il reste trop souvent dans la même stratégie.
=Poster=

Gant de Boxe connecté

2017-01-18T19:52:49Z

Rlentieu : /* Contexte */

=Présentation du sujet =

==Contexte==
De nos jours, nous vivons entourés de plus en plus d'objets connectés y compris dans le domaine sportif afin d'assister (ou de juger/arbitrer).
Dans le cadre du module d'Internet des Objets, nous avons choisi de réaliser un prototype de gant de boxe connecté. Ce prototype permettra au boxeur et à son équipe de connaître le ratio de coups qui auront atteint leur cible.

==Description du projet==
Le gant utilisé contiendra un (ou plusieurs) capteur de pression placé sur la surface de frappe, ainsi qu'un accéléromètre. Le premier nous permettra de compter le nombre de coups atteints et le second le nombre de coups tentés.
Enfin nous utiliserons un arduino afin de communiquer en BLE (Bluetooth Low Energy) avec l'ordinateur du coach qui affichera les résultats.

=Matériel utilisé=
Par gant:

*Accéléromètre [reçu]
*Capteurs de pression flexibles carrés (x4) [reçus]
*RFduino + module BLE [reçu]
*Batterie USB [reçu]

=Suivi de réalisation=
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/01)
| Recherche du sujet et du matériel / Mise en place du cahier des charges
|-
! scope="row" | Séance 2 (05/01)
| Début du développement de la partie Arduino et test de récupération de données
|-
! scope="row" | Séance 3 (12/01)
| Développement de l'application Android
|-
! scope="row" | Séance 4 (13/01)
|
|}

==1ère Séance==
Lors de cette séance, nous avons déterminé le fonctionnement de notre projet mais aussi les technologies à utiliser.
Nous avons donc commencé par rechercher les différentes composants nécessaires à notre projet. Nous avons aussi rechercher certaines informations quand au développement de l'application.

==2ème Séance==

Pendant cette séance nous avons commencé à programmer la partie arduino en ayant au préalable importé les différentes librairies du RFduino. Nous nous sommes renseigné sur les différentes frameworks existantes pour la programmation de BLE.
Suite à cela, nous avons choisi de faire une application android communiquant en bluetooth. Celle-ci serait d'avantage mobile qu'une application ordinateur et plairait d'avantage à un sportif qui pourrait voir directement ses résultats pendant son entraînement ou à son entraîneur qui transporte plus facilement une tablette qu'un ordinateur.

Lors de cette séance, nous avons également commencé à tester notre matériel avec un programme simple sur Arduino qui nous permet de voir que nous recevons bien les données voulues.

==3ème Séance==
Après avoir réalisé en partie le côté RFduino, nous sommes maintenant passés à la partie Android. Pour cela, nous avons choisi d'utiliser l'IDE Android Studio qui va nous permettre de créer notre application.
Cette application devra donc activer le Bluetooth de la tablette s'il n'est pas activé, scanner les alentours afin de capter l'ID du RFduino puis enfin s'y connecter.
Nous arrivons donc bien à détecter notre RFduino. Il nous reste maintenant à nous y connecter afin de pouvoir recevoir les valeurs des capteurs.
Une fois ces valeurs bien reçues, nous devrons les afficher sur l'application sous forme de tableau ou de graphique.

==4ème séance==
Nous avons donc réussi à connecter le RFduino avec l'application. Nous avons donc coder la réception des données du côté de l'application mais aussi le traitement de ces données.
On enregistre les valeurs reçues puis on affiche les données importantes pour un boxeur : le nombre de coups tentés et le nombre de coups touchés.
De plus, nous avons également différencié trois grands types de coups "fréquents" lors d'un match de boxe : le jab, le coup droit et l'uppercut.
Chacun de ces coups suivant principalement un axe différent, il est relativement simple de les différencier.
Ainsi on peut savoir si l'utilisateur différencie ses coups ou s'il reste trop souvent dans la même stratégie.
=Poster=

Gant de Boxe connecté

2017-01-18T19:52:11Z

Rlentieu :

=Présentation du sujet =

==Contexte==
De nos jours, nous vivons entourés de plus en plus d'objets connectés y compris dans le domaine sportif afin d'assister (ou de juger/arbitrer).
Dans le cadre du module d'Internet des Objets, nous avons choisi de réaliser un prototype de gant de boxe connecté. Ce prototype permettra au boxeur et à son équipe de savoir en temps réel le ratio de coups qui auront atteint leur cible.

==Description du projet==
Le gant utilisé contiendra un (ou plusieurs) capteur de pression placé sur la surface de frappe, ainsi qu'un accéléromètre. Le premier nous permettra de compter le nombre de coups atteints et le second le nombre de coups tentés.
Enfin nous utiliserons un arduino afin de communiquer en BLE (Bluetooth Low Energy) avec l'ordinateur du coach qui affichera les résultats.

=Matériel utilisé=
Par gant:

*Accéléromètre [reçu]
*Capteurs de pression flexibles carrés (x4) [reçus]
*RFduino + module BLE [reçu]
*Batterie USB [reçu]

=Suivi de réalisation=
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/01)
| Recherche du sujet et du matériel / Mise en place du cahier des charges
|-
! scope="row" | Séance 2 (05/01)
| Début du développement de la partie Arduino et test de récupération de données
|-
! scope="row" | Séance 3 (12/01)
| Développement de l'application Android
|-
! scope="row" | Séance 4 (13/01)
|
|}

==1ère Séance==
Lors de cette séance, nous avons déterminé le fonctionnement de notre projet mais aussi les technologies à utiliser.
Nous avons donc commencé par rechercher les différentes composants nécessaires à notre projet. Nous avons aussi rechercher certaines informations quand au développement de l'application.

==2ème Séance==

Pendant cette séance nous avons commencé à programmer la partie arduino en ayant au préalable importé les différentes librairies du RFduino. Nous nous sommes renseigné sur les différentes frameworks existantes pour la programmation de BLE.
Suite à cela, nous avons choisi de faire une application android communiquant en bluetooth. Celle-ci serait d'avantage mobile qu'une application ordinateur et plairait d'avantage à un sportif qui pourrait voir directement ses résultats pendant son entraînement ou à son entraîneur qui transporte plus facilement une tablette qu'un ordinateur.

Lors de cette séance, nous avons également commencé à tester notre matériel avec un programme simple sur Arduino qui nous permet de voir que nous recevons bien les données voulues.

==3ème Séance==
Après avoir réalisé en partie le côté RFduino, nous sommes maintenant passés à la partie Android. Pour cela, nous avons choisi d'utiliser l'IDE Android Studio qui va nous permettre de créer notre application.
Cette application devra donc activer le Bluetooth de la tablette s'il n'est pas activé, scanner les alentours afin de capter l'ID du RFduino puis enfin s'y connecter.
Nous arrivons donc bien à détecter notre RFduino. Il nous reste maintenant à nous y connecter afin de pouvoir recevoir les valeurs des capteurs.
Une fois ces valeurs bien reçues, nous devrons les afficher sur l'application sous forme de tableau ou de graphique.

==4ème séance==
Nous avons donc réussi à connecter le RFduino avec l'application. Nous avons donc coder la réception des données du côté de l'application mais aussi le traitement de ces données.
On enregistre les valeurs reçues puis on affiche les données importantes pour un boxeur : le nombre de coups tentés et le nombre de coups touchés.
De plus, nous avons également différencié trois grands types de coups "fréquents" lors d'un match de boxe : le jab, le coup droit et l'uppercut.
Chacun de ces coups suivant principalement un axe différent, il est relativement simple de les différencier.
Ainsi on peut savoir si l'utilisateur différencie ses coups ou s'il reste trop souvent dans la même stratégie.
=Poster=

Gant de Boxe connecté

2017-01-12T15:18:57Z

Rlentieu : /* Suivi de réalisation */

=Présentation du sujet =

==Contexte==
De nos jours, nous vivons entourés de plus en plus d'objets connectés y compris dans le domaine sportif afin d'assister (ou de juger/arbitrer).
Dans le cadre du module d'Internet des Objets, nous avons choisi de réaliser un prototype de gant de boxe connecté. Ce prototype permettra au boxeur et à son équipe de savoir en temps réel le ratio de coups qui auront atteint leur cible.

==Description du projet==
Le gant utilisé contiendra un (ou plusieurs) capteur de pression placé sur la surface de frappe, ainsi qu'un accéléromètre. Le premier nous permettra de compter le nombre de coups atteints et le second le nombre de coups tentés.
Enfin nous utiliserons un arduino afin de communiquer en BLE (Bluetooth Low Energy) avec l'ordinateur du coach qui affichera les résultats.

=Matériel utilisé=
Par gant:

*Accéléromètre [reçu]
*Capteurs de pression flexibles carrés (x4) [reçus]
*RFduino + module BLE [reçu]
*Batterie USB [reçu]

=Suivi de réalisation=
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/01)
| Recherche du sujet et du matériel / Mise en place du cahier des charges
|-
! scope="row" | Séance 2 (05/01)
| Début du développement de la partie Arduino et test de récupération de données
|-
! scope="row" | Séance 3 (12/01)
| Développement de l'application Android
|-
! scope="row" | Séance 4 (13/01)
|
|}

==1ère Séance==
Lors de cette séance, nous avons déterminé le fonctionnement de notre projet mais aussi les technologies à utiliser.
Nous avons donc commencé par rechercher les différentes composants nécessaires à notre projet. Nous avons aussi rechercher certaines informations quand au développement de l'application.

==2ème Séance==

Pendant cette séance nous avons commencé à programmer la partie arduino en ayant au préalable importé les différentes librairies du RFduino. Nous nous sommes renseigné sur les différentes frameworks existantes pour la programmation de BLE.
Suite à cela, nous avons choisi de faire une application android communiquant en bluetooth. Celle-ci serait d'avantage mobile qu'une application ordinateur et plairait d'avantage à un sportif qui pourrait voir directement ses résultats pendant son entraînement ou à son entraîneur qui transporte plus facilement une tablette qu'un ordinateur.

Lors de cette séance, nous avons également commencé à tester notre matériel avec un programme simple sur Arduino qui nous permet de voir que nous recevons bien les données voulues.

==3ème Séance==
Après avoir réalisé en partie le côté RFduino, nous sommes maintenant passés à la partie Android. Pour cela, nous avons choisi d'utiliser l'IDE Android Studio qui va nous permettre de créer notre application.
Cette application devra donc activer le Bluetooth de la tablette s'il n'est pas activé, scanner les alentours afin de capter l'ID du RFduino puis enfin s'y connecter.
Nous arrivons donc bien à détecter notre RFduino. Il nous reste maintenant à nous y connecter afin de pouvoir recevoir les valeurs des capteurs.
Une fois ces valeurs bien reçues, nous devrons les afficher sur l'application sous forme de tableau ou de graphique.

==4ème séance==

=Poster=

Gant de Boxe connecté

2017-01-12T15:18:29Z

Rlentieu : /* 3ème Séance */

=Présentation du sujet =

==Contexte==
De nos jours, nous vivons entourés de plus en plus d'objets connectés y compris dans le domaine sportif afin d'assister (ou de juger/arbitrer).
Dans le cadre du module d'Internet des Objets, nous avons choisi de réaliser un prototype de gant de boxe connecté. Ce prototype permettra au boxeur et à son équipe de savoir en temps réel le ratio de coups qui auront atteint leur cible.

==Description du projet==
Le gant utilisé contiendra un (ou plusieurs) capteur de pression placé sur la surface de frappe, ainsi qu'un accéléromètre. Le premier nous permettra de compter le nombre de coups atteints et le second le nombre de coups tentés.
Enfin nous utiliserons un arduino afin de communiquer en BLE (Bluetooth Low Energy) avec l'ordinateur du coach qui affichera les résultats.

=Matériel utilisé=
Par gant:

*Accéléromètre [reçu]
*Capteurs de pression flexibles carrés (x4) [reçus]
*RFduino + module BLE [reçu]
*Batterie USB [reçu]

=Suivi de réalisation=
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/01)
| Recherche du sujet et du matériel / Mise en place du cahier des charges
|-
! scope="row" | Séance 2 (05/01)
| Début du développement de la partie Arduino et test de récupération de données
|-
! scope="row" | Séance 3 (12/01)
| Développement de l'application Android
|-
! scope="row" | Séance 4 (13/01)
|
|}

==1ère Séance==
Lors de cette séance, nous avons déterminé le fonctionnement de notre projet mais aussi les technologies à utiliser.
Nous avons donc commencé par rechercher les différentes composants nécessaires à notre projet. Nous avons aussi rechercher certaines informations quand au développement de l'application.

==2ème Séance==

Pendant cette séance nous avons commencé à programmer la partie arduino en ayant au préalable importé les différentes librairies du RFduino. Nous nous sommes renseigné sur les différentes frameworks existantes pour la programmation de BLE.
Suite à cela, nous avons choisi de faire une application android communiquant en bluetooth. Celle-ci serait d'avantage mobile qu'une application ordinateur et plairait d'avantage à un sportif qui pourrait voir directement ses résultats pendant son entraînement ou à son entraîneur qui transporte plus facilement une tablette qu'un ordinateur.

Lors de cette séance, nous avons également commencé à tester notre matériel avec un programme simple sur Arduino qui nous permet de voir que nous recevons bien les données voulues.

==3ème Séance==
Après avoir réalisé en partie le côté RFduino, nous sommes maintenant passés à la partie Android. Pour cela, nous avons choisi d'utiliser l'IDE Android Studio qui va nous permettre de créer notre application.
Cette application devra donc activer le Bluetooth de la tablette s'il n'est pas activé, scanner les alentours afin de capter l'ID du RFduino puis enfin s'y connecter.
Nous arrivons donc bien à détecter notre RFduino. Il nous reste maintenant à nous y connecter afin de pouvoir recevoir les valeurs des capteurs.
Une fois ces valeurs bien reçues, nous devrons les afficher sur l'application sous forme de tableau ou de graphique.

=Poster=

Gant de Boxe connecté

2017-01-12T15:16:08Z

Rlentieu : /* Suivi de réalisation */

Gant de Boxe connecté

2017-01-12T15:12:32Z

Rlentieu : /* Suivi de réalisation */

Gant de Boxe connecté

2017-01-12T15:10:30Z

Rlentieu : /* 1ère Séance */

Gant de Boxe connecté

2017-01-12T15:08:06Z

Rlentieu : /* Suivi de réalisation */

Gant de Boxe connecté

2017-01-12T15:06:03Z

Rlentieu : /* Matériel utilisé */

Gant de Boxe connecté

2017-01-10T07:22:57Z

Rlentieu : /* Matériel utilisé */

Gant de Boxe connecté

2017-01-10T07:21:40Z

Rlentieu : /* Matériel utilisé */

Cahier 2016 groupe n°6

2017-01-06T11:12:54Z

Rlentieu : /* Suite Sécurisation SSL */

== Cahier des charges ==
=== Présentation du travail ===

Voici le schéma du projet à mettre en place lors du module de Protocoles Réseaux Avancés:

[[Fichier:Travail.jpeg||600px||center]]
==== Répartition du travail ====

{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/10)
| Connaissances du TP/ Recherche sur le routeur 3560E / Installation de la machine virtuelle
|-
! scope="row" | Séance 2 (10/10)
| Création des VLAN
|-
! scope="row" | Séance 3 (13/10)
| Création des VLAN / Création de la machine virtuelle
|-
! scope="row" | Séance 4 (24/10)
| Crackage de clé WEP
|-
! scope="row" | Séance 5 (07/11)
| Configuration Eeepc / Crackage clé WPA / Test de la configuration locale
|-
! scope="row" | Séance 6 (14/11)
| Configuration machine virtuelle / Configuration routeur ipv6 / interconnexion ipv4 et ipv6 / HSRP
|-
! scope="row" | Séance 7 (28/11)
| Configuration machine Virtuelle SSL / DNSSEC / Partition RAID5 / Cryptage des données
|-
! scope="row" | Séance 8 (05/12)
| Configuration Routeur pour Point d'Accès WIFI / Sécurisation Wifi par WPA2-EAP
|-
! scope="row" | Séance 9 (12/12)
| Configuration Asterisk et test de la VoIP
|}

===Réalisation 1ère semaine ===

Pour la première séance nous nous sommes chargés d'installer la machine virtuelle Xen à l'aide de la commande :
<pre>
xen-create-image --hostname=Kadoc --ip=193.48.57.166 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --gateway=193.48.57.172
--netmask=255.255.255.240 --dir=/usr/local/xen --passwd
</pre>
Ainsi, nous obtenons ce résultat:
<pre>
Installation Summary
---------------------
Hostname : Kadoc
Distribution : jessie
MAC Address : 00:16:3E:60:01:B1
IP Address(es) : 193.48.57.166
RSA Fingerprint : cf:03:35:4e:b7:f1:d4:f5:52:a1:d7:52:63:5d:83:57
Root Password : N/A
</pre>

===Réalisation 2ème semaine ===
=====VLANs=====
Durant les deux séances de cette semaine, nous avons réalisé la configuration locale du routeur 3560E, notamment la configuration des VLANs.

Pour cela, nous avons utilisé la communication série.
Lors du démarrage, nous devons le configurer :
<pre>
conf t
hostname Perceval
enable secret pasglop
</pre>

Nous passons maintenant à la configuration des VLANs:

Nous avons 11 VLANs à configurer :
* VLAN2 à VLAN11 : un pour chaque groupe
* VLAN12 : pour les machines virtuelles et donc le lien entre Cordouan et les commutateurs
* VLAN13 : pour l'interconnexion, c'est à dire le lien entre notre routeur et le routeur de l'école.

Pour la configuration, nous prendrons l'exemple du vlan 2.
Tout d'abord, nous affectons aux VLANs utiles:
<pre>
vlan 2
name Vlan2
exit
</pre>

Une fois le nom affecté :
<pre>
conf t
int Vlan2
ip address 10.60.2.2 255.255.255.0
exit
</pre>

=====Machine virtuelle=====

Tout d'abord, nous nous connectons sur le serveur cordouan:
<pre>
ssh root@cordouan.insecserv.deule.net
</pre>

Nous créons ensuite la machine avec tous les renseignements souhaités
<pre>
xen-create-image --hostname=Kadoc --ip=193.48.57.166 --netmask=255.255.255.240 --gateway=193.48.57.172
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie
</pre>
Enfin on démarre la machine virtuelle
<pre>
xl create /etc/xen/Kadoc.cfg
</pre>
Puis nous la lançons
<pre>
xl console Kadoc
</pre>

Lors de cette séance, nous avons aussi réservé notre nom de domaine sur Gandi : hamtaro.space

Nous avons également modifier le fichier de configuration de la VM en modifiant le fichier "/etc/xen/Kadoc.cfg" pour la taille mémoire 'de 128 à 512MB" ainsi que pour ajouter le bridge IMA5sc.

===Réalisation 3ème semaine ===
=====crackage clé WEP=====
1ere commande : airodump-ng --encrypt wep wlan2
BSSID PWR Beacons #data #/s CH MB ENC CIPHER AUTH ESSID
04:DA:D2:9C:50:56 -57 1 65 32 2 54e. WEP WEP cracotte07

La cible que nous avons choisie est "cracotte07", donc on utilise la commande suivante :

airodump-ng --essid cracotte07 --channel 2 -w testcrack wlan2

On obtient:

CH 2 ][ Elapsed: 3 mins ][ 2014-12-12 18:15
<pre>
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
04:DA:D2:9C:50:56 -55 6 505 9516 231 2 54e. WEP WEP cracotte07
</pre>
Le monitoring est donc lancé, nous pouvons passer au crackage :
aircrack-ng testcrack-01.cap

On obtient finalement la clé :

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:E4:44:44:44 ]
Decrypted correctly: 100%

===Réalisation 4ème semaine===

=====Configuration eeePC =====
''SSH:''

On modifie le fichier /etc/resolv.conf
<pre>
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
</pre>

Pour pouvoir se connecter en ssh il est nécessaire de modifier le ficher /etc/network/interfaces de la façon suivante :
rajouter les lignes :
<pre>
auto wlan2
iface wlan2 inet static
wireless mode-managed
wireless essid Wolverine // pour se connecter à la borne Wifi
wireless-key 0123456789 // mot de passe de la borne
address 172.26.79.22 // notre adresse
netmask 255.255.255.240
gateway 172.26.79.254
</pre>

''Intrusion par changement d'adresse MAC''
En changeant notre adresse MAC grâce à la commande
<pre>
ifconfig wlan2 down
ifconfig wlan2 hw ether 74:29:af:f3:fd:71
ifconfig wlan2 up
</pre>
On ne peut plus se connecter.

=====Crackage clé WPA=====

On effectue la même démarche que pour le crackage de la clé WEP pour :
<pre>
airodump-ng --encrypt wpa wlan1
</pre>
On choisit de cracker cracotte03
<pre>
airodump-ng -w out --encrypt wpa -c 13 --bssid 04:DA:D2:9C:50:52 wlan1
</pre>
On obtient le handshake 04:DA:D2:9C:50:52

On crée le dictionnaire grâce à la commande :
<pre>
crunch 8 8 0123456789 > dico.txt
</pre>
On lance ensuite :
<pre>
airodump-ng --essid cracotte03 -c 13 --bssid 04:DA:D2:9C:50:52 -w dump wlan1
</pre>
On décode ensuite le fichier dump grâce à la commande :
<pre>
aircrack-ng dump-01.cap -w dico.txt -l KEY
</pre>
Après un long moment on obtient le résultat, la clé WPA est
<pre>
12399903
</pre>

=====Test configuration routeur=====
Pour tester la configuration de notre routeur, il fallait le relier au commutateur qui devait être relié au serveur cordouan.
Or pour cela, il nous était impossible de le relier en filaire. Nous avons donc utilisé la fibre.
Nous avons donc dû utiliser un convertisseur de l'interface 10Gi en deux interfaces Gi.
Une fois cela effectué, nous pouvions relier la fibre au commutateur qui était lui-même relié au serveur Cordouan.
Il fallait seulement changer le mode access du port sur le commutateur et le configurer en Trunk.

Une fois cela effectué et bien configuré, nous parvenons à "pinger" notre routeur depuis notre machine virtuelle.

<pre>
# ping 193.48.57.172
PING 193.48.57.172 (193.48.57.172) 56(84) bytes of data.
64 bytes from 193.48.57.172: icmp_seq=1 ttl=255 time=6.23 ms
64 bytes from 193.48.57.172: icmp_seq=2 ttl=255 time=1.01 ms
64 bytes from 193.48.57.172: icmp_seq=3 ttl=255 time=19.8 ms
64 bytes from 193.48.57.172: icmp_seq=4 ttl=255 time=1.56 ms
64 bytes from 193.48.57.172: icmp_seq=5 ttl=255 time=8.55 ms
64 bytes from 193.48.57.172: icmp_seq=6 ttl=255 time=2.36 ms
^C
--- 193.48.57.172 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 1.018/6.593/19.818/6.495 ms
</pre>

===Réalisation 5ème semaine ===

=====Configuration machine virtuelle=====
Installation des packages ssh, apache2 et bind9.

Modification du fichier :
<pre>
/etc/bind/db.hamtaro.space
</pre>

<pre>
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hamtaro.space. root.hamtaro.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN NS ns.hamtaro.space.
IN NS ns6.gandi.net.
IN MX 100 ns.hamtaro.space.

ns IN A 193.48.57.166
www IN A 193.48.57.166

</pre>

Modification du fichier :
<pre>
/etc/bind/named.conf.local
</pre>

<pre>
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "hamtaro.space" IN {
type master;
file "/etc/bind/db.hamtaro.space";
allow-transfer {217.70.177.40;};
};
</pre>

On va ensuite sur le site de Gandi pour modifier des informations.
Les Glue Records :
<pre>
'Nom du serveur' : ns.hamtaro.space
'IP' : 193.48.57.166
</pre>

Puis dans la rubrique modifier les serveurs DNS :
<pre>
'DNS1' : ns.hamtaro.space
'DNS2' : ns6.gandi.net
</pre>

Sécurisation de site web par certificat :

On tape la commande :
<pre>
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hamtaro.space.key -out hamtaro.space.csr
</pre>

Puis on remplis les champs demandés :
<pre>
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:hamtaro.space
</pre>

On se rend ensuite sur le site de Gandi et on rentre le contenu du fichier hamtaro.space.csr dans le champs CSR prévu à cet effet puis nous attendons la validation de notre certificat.

===== Configuration routeur=====
Configuration IPV6 des Vlan:
<pre>
ipv6 enable
ipv6 address 2001:660:4401:60XX::/64 eui-64
ipv6 nd prefix 2001:660:4401:60XX::/64 1000 900
</pre>

Avec les valeurs de XX variant de B0 à BA.
Pour le vlan130, cette valeur change : AA.

Interconnexion IPV4:
<pre>
router ospf 1
router-id 10.60.2.2
summary-address 10.60.0.0 255.255.0.0
summary-address 193.48.57.160 255.255.255.240
redistribute connected metric 30 subnets
network 192.168.222.0 0.0.0.7 area 1
</pre>

Interconnexion IPV6:
<pre>
ipv6 router rip tpima5sc
redistribute connected metric 1
redistribute static metric 1
redistribute rip 1 metric 1
</pre>

Une fois cela effectué, il faut que le vlan d'interconnexion prenne en compte ces modifications, il faut donc ajouter la commande :
<pre>
ipv6 rip tpima5sc enable
</pre>
Enfin, pour confirmer la configuration effectuée, nous affichons la table de routage ipv6 :
sh ipv6 route

On obtient alors le résultat suivant :
<pre>
IPv6 Routing Table - Default - 65 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, D - EIGRP, EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R ::/0 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:60::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6000::/56 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6002::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6003::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6004::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6005::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6006::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6007::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6008::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6009::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6011::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6013::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6014::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6015::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6016::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
...
</pre>

On essaie ensuite de ping le site de google depuis la machine virtuelle. On obtient un résultat positif. Notre configuration est donc fonctionnelle.

===== Sécurisation du réseau par HSRP =====
Pour empêcher les pertes de transmission de paquets, il faut ajouter une passerelle sur chaque interface.
De plus il faut ajouter l'adresse du routeur virtuel sur le vlan des machines virtuelles à savoir : 193.48.57.173.
On a alors :
<pre>
interface Vlan12
ip address 193.48.57.172 255.255.255.240
standby 1 ip 193.48.57.173
standby 1 priority 110
standby 1 preempt
</pre>

Une fois cela effectué sur notre routeur mais aussi sur le routeur de Stéphane et Thomas (groupe 5), nous réussissons à pinger leurs interfaces virtuelles ainsi que les interfaces de la machine virtuelle.
Nous pouvons également voir lors de l'affichage de la configuration en standby que notre routeur est considéré comme local tandis que le leur est en standby. La ligne traitant de la priorité fonctionne donc et permet la redondance du système.

===Réalisation 6ème semaine ===
====Suite Sécurisation SSL====
Après avoir obtenu notre certificat SSL sur le site GANDI, nous pouvons copier les fichiers utiles dans le dossier ssl:
<pre>
root@Kadoc:/etc/bind# cp certificat.crt /etc/ssl/certs/hamtaro.space.crt
root@Kadoc:/etc/bind# cp hamtaro.space.key /etc/ssl/private/hamtaro.space.key
root@Kadoc:/etc/bind# cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem
</pre>

Nous créons le fichier 000-hamtaro.space-ssl.conf dans le dossier "apache2/sites-available" afin de pouvoir joindre notre nom de serveur et Apache:
<pre>
#NameVirtualHost *:443
<VirtualHost 193.48.57.166:443>
ServerName www.hamtaro.space
ServerAlias hamtaro.space
DocumentRoot /var/www/www.hamtaro.space/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/hamtaro.space.crt
SSLCertificateKeyFile /etc/ssl/private/hamtaro.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem
SSLVerifyClient None
</VirtualHost>
<Directory /var/www/www.hamtaro.space>
Require all granted
</Directory>
ServerName "hamtaro.space"
</pre>

Enfin, nous devons modifier le fichier ports.conf afin que le serveur Apache écoute sur le port 443.
<pre>
Listen 80 443

<IfModule ssl_module>
Listen 443
</IfModule>

#<IfModule mod_gnutls.c>
# Listen 443
#</IfModule>

#<IfModule mod_ssl.c>
# Listen 443
#NameVirtualHost *:443
#</IfModule>
</pre>

Nous pouvons désormais activer le module SSL de apache :
<pre>a2enmod ssl</pre>

Puis nous pouvons activer notre certificat pour notre site :
<pre>
a2ensite 000-hamtaro.space-ssl.conf
Enabling site 000-hamtaro.space-ssl.
service apache2 reload //afin de charger la nouvelle configuration.
</pre>

Nous pouvons donc maintenant voir que notre site est sécurisé en allant sur https://www.hamtaro.space 
Il y a en effet le cadenas vert symbolisant cela:

[[Fichier:Screensecuresite.png]]

====Sécurisation par DNSSEC====

Dans un premier temps on va modifier le fichier /etc/bind/named.conf.options et rajouter la ligne :
<pre>
dnssec-enable yes
</pre>

Nous devons maintenant générer les clés (fichiers KSK et ZSK) que nous utiliserons afin de signer les zones:
<pre>
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hamtaro.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hamtaro.space
</pre>

Nous les plaçons dans un dossier nommé hamtaro.space.dnssec.

Nous modifions ensuite le fichier db.hamtaro.space afin d'inclure ces deux clés:
<pre>
$include /etc/bind/hamtaro.space.dnssec/hamtaro.space-ksk.key
$include /etc/bind/hamtaro.space.dnssec/hamtaro.space-zsk.key
</pre>

Il nous faut maintenant signer la zone :
<pre> dnssec-signzone -o hamtaro.space -k hamtaro.space-ksk ../db.hamtaro.space hamtaro.space-zsk
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.hamtaro.space.signed
</pre>

Nous ajoutons ensuite le DNSSEC sur Gandi :
[[Fichier:dnssecKadoc.png]]

On peut ensuite vérifier que notre DNSSEC est bien sécurisé :
<pre>
root@Kadoc:/etc/bind# dig DNSKEY hamtaro.space @localhost

; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> DNSKEY hamtaro.space @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5615
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;hamtaro.space. IN DNSKEY

;; AUTHORITY SECTION:
hamtaro.space. 604800 IN SOA ns.hamtaro.space. root.hamtaro.space.hamtaro.space. 3 604800 86400 2419200 604800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 28 13:21:10 CET 2016
;; MSG SIZE rcvd: 100

</pre>

====Partition RAID5====
Pour assurer la sécurisation des données, nous configurons trois partitions de volumes logiques sur la machine virtuelle:

<pre>
lvcreate -L 1G -n /dev/virtual/ima5-lapoulette
lvcreate -L 1G -n /dev/virtual/ima5-Karadoc
lvcreate -L 1G -n /dev/virtual/ima5-pelinord
</pre>

Puis nous modifions le fichier de configuration de notre machine virtuelle :
<pre>
disk = [
'file:/usr/local/xen/domains/Kadoc/disk.img,xvda2,w',
'file:/usr/local/xen/domains/Kadoc/swap.img,xvda1,w',
'phy:/dev/virtual/ima5-pelinord,xvdb,w',
'phy:/dev/virtual/ima5-Karadoc,xvdc,w',
'phy:/dev/virtual/ima5-lapoulette,xvdd,w',
]
</pre>

Nous pouvons maintenant relancer notre machine virtuelle.
Nous pouvons y créer le RAID5 avec les 3 partitions:
<pre> mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdb /dev/xvdc /dev/xvdd </pre>

On peut ensuite voir le détail de la configuration :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 12:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Nov 29 13:18:04 2016
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : 90156134:39a740fa:0de8c29d:486dce2c
Events : 22

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
1 202 32 1 active sync /dev/xvdc
3 202 48 2 active sync /dev/xvdd
</pre>

Nous devons ensuite sauvegarder cette configuration afin de garder notre md0, pour cela:
<pre> mdadm --detail --scan >> /etc/mdadm/mdadm.conf </pre>
puis nous pouvons copier les données sur le RAID5:
<pre>
root@Kadoc:~# mkfs /dev/md0
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 523776 4k blocks and 131072 inodes
Filesystem UUID: 2703e116-ed2c-46fe-964a-928be0b34cd6
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
</pre>
Puis:
<pre>
root@Kadoc:~# mount /dev/md0 /mnt
[ 702.230079] EXT4-fs (md0): mounting ext2 file system using the ext4 subsystem
[ 702.309734] EXT4-fs (md0): mounted filesystem without journal. Opts: (null)
</pre>

Nous allons maintenant voir ce qu'il se passe lorsque l'on enlève une des partitions à la machine.
Nous redémarrons la machine virtuelle et nous affichons le détail :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 12:23:50 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Tue Nov 29 12:43:56 2016
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : b333670e:27b24fbe:045a7e98:c7eafb49
Events : 14

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
2 0 0 2 removed
2 202 48 2 active sync /dev/xvdd
</pre>

Nous voyons donc bien qu'une partition a été enlevée.
Pour réparer cela,
<pre>
mdadm --set-faulty /dev/md0 /dev/xvdc
mdadm --remove /dev/md0 /dev/xvdc
</pre>

La partition est bien supprimée:
<pre>
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdb[0] xvdd[3]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
</pre>

On remet la partition:
<pre>mdadm --add /dev/md0 /dev/xvdc</pre>

On peut ensuite suivre l'avancement de la restauration:
<pre>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===========>.........] recovery = 56.9% (596964/1047552) finish=0.2min speed=29848K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=============>.......] recovery = 66.9% (701992/1047552) finish=0.1min speed=29249K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===============>.....] recovery = 75.0% (786728/1047552) finish=0.1min speed=29138K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=================>...] recovery = 85.1% (892660/1047552) finish=0.0min speed=29755K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 99.6% (1044732/1047552) finish=0.0min speed=30465K/sec

unused devices: <none>
root@Kadoc:/dev# [ 156.292138] md: md0: recovery done.
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>
</pre>

Enfin, on retrouve la configuration initiale :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Nov 29 13:18:04 2016
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : 90156134:39a740fa:0de8c29d:486dce2c
Events : 22

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
1 202 32 1 active sync /dev/xvdc
3 202 48 2 active sync /dev/xvdd
</pre>

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

Pour cette partie, nous commençons par installer lvm2, Gparted ainsi que cryptsetup sur notre eeePc.
Nous voulons une seule partition sur la carte SD. Pour cela on utilise:
<pre>
fdisk /dev/mmcblk1
</pre>
On créé alors une partition primaire sur tout l'espace disponible de la carte.

Une fois cette partition créée, elle n'est pas cryptée, nous allons donc maintenant utiliser le cryptsetup:

<pre>
cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
</pre>
Cette commande permet de formatter la partition au type Luks avec un chiffrement AES avec un algorithme de hâchage SHA256.
On doit aussi choisir un mot de passe pour crypter la partition.

Pour voir l'état du conteneur, on peut utiliser la commande :
<pre>
root@lamproie:~# cryptsetup luksDump /dev/mmcblk1
LUKS header information for /dev/mmcblk1

Version: 1
Cipher name: aes
Cipher mode: cbc-plain
Hash spec: sha256
Payload offset: 4096
MK bits: 256
MK digest: b9 ed bc f9 68 3c ac 64 d4 3b a4 44 5b 48 38 b2 d1 b4 7d 87
MK salt: 8a a5 f6 38 a7 08 fe 6b 90 7d 88 79 10 fc 70 15
95 e0 67 82 ee 34 fe 87 23 3e 2a 77 f7 ed cf 35
MK iterations: 125750
UUID: 07082d69-6117-42f8-81a3-695d1ea8e5df

Key Slot 0: ENABLED
Iterations: 1007873
Salt: 98 b5 bd 00 ca 5b 70 81 62 50 8d 5f ba ea d9 4c
35 38 70 bf 09 0b da 95 51 cb 81 c0 35 2d fe da
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
</pre>

On ouvre ensuite notre partition cryptée:
<pre> cryptsetup luksOpen /dev/mmcblk1 kadoc </pre>

On peut ainsi ajouter le système de fichiers à notre partition cryptée:
<pre>mkfs.ext3 /dev/mapper/kadoc</pre>

Ensuite, nous pouvons monter la partition pour pouvoir y écrire. Nous pouvons aussi la démonter lorsque nos fichiers seront copiés:
<pre>
mount -t ext3 /dev/mapper/kadoc /mnt/ //pour monter la partition.

umount /mnt/ //pour démonter la partition.
</pre>

Enfin pour encrypter à nouveau cette partition, on utilise la commande:
<pre> cryptsetup luksClose kadoc </pre>

On utilise la commande <pre> gparted /dev/mmcblk1 </pre> afin de voir la partition, on obtient ceci:

[[Fichier:Screencrypt.png]]

On voit donc que les informations de cette partition ne sont pas disponibles à moins d'avoir la clé.

===Réalisation 7ème semaine ===
Lors de cette semaine nous avons pu connecter le points d'accès Wifi de Valentin et Alexandre sur le commutateur de la salle E304. Pour cela, nous avons dû configurer un vlan1 sur le routeur qui prend l'adresse 10.60.1.3.
Ainsi, nous avons pu nous trouver ce point d'accès qui a pris l'adresse 10.60.1.6.
Nous avions ainsi les deux points d'accès qui étaient connectés dans chaque salle :
En E304 : avec l'adresse 10.60.1.6 et en E306 : 10.60.1.2.

Une fois cela fait, nous pouvons passer à la sécurisation Wifi par WPA2-EAP.

=====Sécurisation Wifi par WPA2-EAP=====
Nous allons utiliser cette méthode afin de créer le point d'accès que nous avons mentionné plus haut et d'en sécuriser la connexion.
Tout d'abord, nous devons créer le serveur FreeRadius:
Nous devons tout d'abord modifier certains fichiers de configuration du serveur :
dans le fichier ''eap.conf'' nous devons modifier une ligne afin de modifier le protocole d'identification :
<pre> default_eap_type = peap </pre>

Une fois cela fait, nous devons modifier le fichier ''clients.conf'', ce qui nous permettra de configurer nos points d'accès Wifi:
<pre>

client E304 {
ipaddr = 10.60.1.6
secret = kadoc
shortname = wifi1
}

client E306 {
ipaddr = 10.60.1.2
secret = kadoc
shortname = wifi2
}
</pre>
Nous avons ainsi configuré les deux points d'accès.

Enfin, nous devons ajouter une ligne au fichier users qui va nous permettre de créer un nouvel utilisateur pour l'identification:
<pre> karadoc Cleartext-Password := "perceval" </pre>

Une fois cela fait, nous pouvons lancer notre serveur FreeRadius.

Nous allons maintenant passer à la configuration du point d'accès afin d'avoir un accès sécurisé avec notre serveur précédemment détaillé:
<pre>
telnet 10.60.1.6

...

conf t

aaa new-model
aaa authentication login eap_kadoc group radius_kadoc
radius-server host 193.48.57.166 auth-port 1812 acct-port 1813 key kadoc
aaa group server radius radius_kadoc
server 193.48.57.166 auth-port 1812 acct-port 1813

exit

dot11 ssid SSID_KADOC
vlan 7
authentication open eap eap_kadoc
authentication network-eap eap_kadoc
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 7 mode ciphers aes-ccm tkip
ssid SSID_KADOC

exit

interface Dot11Radio0.7
encapsulation dot1Q 7
no ip route-cache
bridge-group 7
bridge-group 7 subscriber-loop-control
bridge-group 7 spanning-disabled
bridge-group 7 block-unknown-source
no bridge-group 7 source-learning
no bridge-group 7 unicast-flooding

exit

interface GigabitEthernet0.7
encapsulation dot1Q 7
bridge-group 7

exit

exit

write
</pre>

La borne est maintenant configurée, il ne nous reste plus qu'à nous y connecter.

Pour cela, nous devons encore modifier le wlan0 de l'eeepc.
Nous modifions donc le fichier /etc/network/interfaces :
<pre>
auto wlan0
iface wlan0 inet static
address 10.60.7.7
netmask 255.255.255.0
gateway 10.60.7.1
wpa-ssid KADOC
wpa-key-mgmt WPA-EAP
wpa-identity karadoc
wpa-password perceval
</pre>

Une fois cela fait, nous pouvons nous connecter sur le point d'accès de la salle E304. Pour se connecter sur celui de la E306, il faudrait faire la même configuration sur ce point d'accès.
Nous avons réussi à nous connecter à ce point d'accès en rentrant une adresse IP valide à la main. Pour rendre cela automatique, nous devrons installer un serveur DHCP sur notre Eeepc qui nous permettre d'attribuer une adresse IP à notre smartphone
Une fois notre serveur DHCP installé et correctement configuré, nous pouvons nous connecter comme prévu sans avoir à rentrer une adresse IP "à la main".

[[Fichier:KadocConnected.png||200px||center]]

===Réalisation 9ème semaine ===

Nous avons dans un premier temps installer Asterisk
<pre>
apt-get install asterisk
</pre>

Nous avons ensuite configuré le fichier <pre> /etc/asterisk/users.conf </pre> en y ajoutant :
<pre>
[general]
hasvoicemail = yes
hassip = yes
hasiax = yes
callwaiting = yes
threewaycalling = yes
callwaitingcallerid = yes
transfer = yes
canpark = yes
cancallforward = yes
callreturn = yes
callgroup = 1
pickupgroup = 1
nat = yes

[6001]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = kadoc
username = heykadoc
secret = perceval
context = work

[6002]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = karadoc
username = heykaradoc
secret = perceval
context = work
</pre>

Ensuite, on ajoute dans le fichier <pre>/etc/asterisk/extensions.conf :</pre>
<pre>
[work]
exten => _6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()
</pre>

On restart ensuite asterisk :
<pre>
service asterisk restart
</pre>

Puis on reload l'ensemble des fichiers afin qu'ils soient pris en compte :
<pre>
reload
</pre>

On cherche maintenant à savoir si notre configuration fonctionne. Pour cela, nous installons l'application CSipSimple sur deux téléphones Android sur lesquels nous configurons deux comptes.

Lorsque nous essayons de nous appeler, nous voyons que la communication fonctionne:
[[Fichier:15497641_10210148661905836_1314328693_n.jpg||400px||center]]

Cahier 2016 groupe n°6

2017-01-03T14:13:16Z

Rlentieu : /* Présentation du travail */

== Cahier des charges ==
=== Présentation du travail ===

Voici le schéma du projet à mettre en place lors du module de Protocoles Réseaux Avancés:

[[Fichier:Travail.jpeg||600px||center]]
==== Répartition du travail ====

{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/10)
| Connaissances du TP/ Recherche sur le routeur 3560E / Installation de la machine virtuelle
|-
! scope="row" | Séance 2 (10/10)
| Création des VLAN
|-
! scope="row" | Séance 3 (13/10)
| Création des VLAN / Création de la machine virtuelle
|-
! scope="row" | Séance 4 (24/10)
| Crackage de clé WEP
|-
! scope="row" | Séance 5 (07/11)
| Configuration Eeepc / Crackage clé WPA / Test de la configuration locale
|-
! scope="row" | Séance 6 (14/11)
| Configuration machine virtuelle / Configuration routeur ipv6 / interconnexion ipv4 et ipv6 / HSRP
|-
! scope="row" | Séance 7 (28/11)
| Configuration machine Virtuelle SSL / DNSSEC / Partition RAID5 / Cryptage des données
|-
! scope="row" | Séance 8 (05/12)
| Configuration Routeur pour Point d'Accès WIFI / Sécurisation Wifi par WPA2-EAP
|-
! scope="row" | Séance 9 (12/12)
| Configuration Asterisk et test de la VoIP
|}

===Réalisation 1ère semaine ===

Pour la première séance nous nous sommes chargés d'installer la machine virtuelle Xen à l'aide de la commande :
<pre>
xen-create-image --hostname=Kadoc --ip=193.48.57.166 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --gateway=193.48.57.172
--netmask=255.255.255.240 --dir=/usr/local/xen --passwd
</pre>
Ainsi, nous obtenons ce résultat:
<pre>
Installation Summary
---------------------
Hostname : Kadoc
Distribution : jessie
MAC Address : 00:16:3E:60:01:B1
IP Address(es) : 193.48.57.166
RSA Fingerprint : cf:03:35:4e:b7:f1:d4:f5:52:a1:d7:52:63:5d:83:57
Root Password : N/A
</pre>

===Réalisation 2ème semaine ===
=====VLANs=====
Durant les deux séances de cette semaine, nous avons réalisé la configuration locale du routeur 3560E, notamment la configuration des VLANs.

Pour cela, nous avons utilisé la communication série.
Lors du démarrage, nous devons le configurer :
<pre>
conf t
hostname Perceval
enable secret pasglop
</pre>

Nous passons maintenant à la configuration des VLANs:

Nous avons 11 VLANs à configurer :
* VLAN2 à VLAN11 : un pour chaque groupe
* VLAN12 : pour les machines virtuelles et donc le lien entre Cordouan et les commutateurs
* VLAN13 : pour l'interconnexion, c'est à dire le lien entre notre routeur et le routeur de l'école.

Pour la configuration, nous prendrons l'exemple du vlan 2.
Tout d'abord, nous affectons aux VLANs utiles:
<pre>
vlan 2
name Vlan2
exit
</pre>

Une fois le nom affecté :
<pre>
conf t
int Vlan2
ip address 10.60.2.2 255.255.255.0
exit
</pre>

=====Machine virtuelle=====

Tout d'abord, nous nous connectons sur le serveur cordouan:
<pre>
ssh root@cordouan.insecserv.deule.net
</pre>

Nous créons ensuite la machine avec tous les renseignements souhaités
<pre>
xen-create-image --hostname=Kadoc --ip=193.48.57.166 --netmask=255.255.255.240 --gateway=193.48.57.172
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie
</pre>
Enfin on démarre la machine virtuelle
<pre>
xl create /etc/xen/Kadoc.cfg
</pre>
Puis nous la lançons
<pre>
xl console Kadoc
</pre>

Lors de cette séance, nous avons aussi réservé notre nom de domaine sur Gandi : hamtaro.space

Nous avons également modifier le fichier de configuration de la VM en modifiant le fichier "/etc/xen/Kadoc.cfg" pour la taille mémoire 'de 128 à 512MB" ainsi que pour ajouter le bridge IMA5sc.

===Réalisation 3ème semaine ===
=====crackage clé WEP=====
1ere commande : airodump-ng --encrypt wep wlan2
BSSID PWR Beacons #data #/s CH MB ENC CIPHER AUTH ESSID
04:DA:D2:9C:50:56 -57 1 65 32 2 54e. WEP WEP cracotte07

La cible que nous avons choisie est "cracotte07", donc on utilise la commande suivante :

airodump-ng --essid cracotte07 --channel 2 -w testcrack wlan2

On obtient:

CH 2 ][ Elapsed: 3 mins ][ 2014-12-12 18:15
<pre>
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
04:DA:D2:9C:50:56 -55 6 505 9516 231 2 54e. WEP WEP cracotte07
</pre>
Le monitoring est donc lancé, nous pouvons passer au crackage :
aircrack-ng testcrack-01.cap

On obtient finalement la clé :

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:E4:44:44:44 ]
Decrypted correctly: 100%

===Réalisation 4ème semaine===

=====Configuration eeePC =====
''SSH:''

On modifie le fichier /etc/resolv.conf
<pre>
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
</pre>

Pour pouvoir se connecter en ssh il est nécessaire de modifier le ficher /etc/network/interfaces de la façon suivante :
rajouter les lignes :
<pre>
auto wlan2
iface wlan2 inet static
wireless mode-managed
wireless essid Wolverine // pour se connecter à la borne Wifi
wireless-key 0123456789 // mot de passe de la borne
address 172.26.79.22 // notre adresse
netmask 255.255.255.240
gateway 172.26.79.254
</pre>

''Intrusion par changement d'adresse MAC''
En changeant notre adresse MAC grâce à la commande
<pre>
ifconfig wlan2 down
ifconfig wlan2 hw ether 74:29:af:f3:fd:71
ifconfig wlan2 up
</pre>
On ne peut plus se connecter.

=====Crackage clé WPA=====

On effectue la même démarche que pour le crackage de la clé WEP pour :
<pre>
airodump-ng --encrypt wpa wlan1
</pre>
On choisit de cracker cracotte03
<pre>
airodump-ng -w out --encrypt wpa -c 13 --bssid 04:DA:D2:9C:50:52 wlan1
</pre>
On obtient le handshake 04:DA:D2:9C:50:52

On crée le dictionnaire grâce à la commande :
<pre>
crunch 8 8 0123456789 > dico.txt
</pre>
On lance ensuite :
<pre>
airodump-ng --essid cracotte03 -c 13 --bssid 04:DA:D2:9C:50:52 -w dump wlan1
</pre>
On décode ensuite le fichier dump grâce à la commande :
<pre>
aircrack-ng dump-01.cap -w dico.txt -l KEY
</pre>
Après un long moment on obtient le résultat, la clé WPA est
<pre>
12399903
</pre>

=====Test configuration routeur=====
Pour tester la configuration de notre routeur, il fallait le relier au commutateur qui devait être relié au serveur cordouan.
Or pour cela, il nous était impossible de le relier en filaire. Nous avons donc utilisé la fibre.
Nous avons donc dû utiliser un convertisseur de l'interface 10Gi en deux interfaces Gi.
Une fois cela effectué, nous pouvions relier la fibre au commutateur qui était lui-même relié au serveur Cordouan.
Il fallait seulement changer le mode access du port sur le commutateur et le configurer en Trunk.

Une fois cela effectué et bien configuré, nous parvenons à "pinger" notre routeur depuis notre machine virtuelle.

<pre>
# ping 193.48.57.172
PING 193.48.57.172 (193.48.57.172) 56(84) bytes of data.
64 bytes from 193.48.57.172: icmp_seq=1 ttl=255 time=6.23 ms
64 bytes from 193.48.57.172: icmp_seq=2 ttl=255 time=1.01 ms
64 bytes from 193.48.57.172: icmp_seq=3 ttl=255 time=19.8 ms
64 bytes from 193.48.57.172: icmp_seq=4 ttl=255 time=1.56 ms
64 bytes from 193.48.57.172: icmp_seq=5 ttl=255 time=8.55 ms
64 bytes from 193.48.57.172: icmp_seq=6 ttl=255 time=2.36 ms
^C
--- 193.48.57.172 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 1.018/6.593/19.818/6.495 ms
</pre>

===Réalisation 5ème semaine ===

=====Configuration machine virtuelle=====
Installation des packages ssh, apache2 et bind9.

Modification du fichier :
<pre>
/etc/bind/db.hamtaro.space
</pre>

<pre>
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hamtaro.space. root.hamtaro.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN NS ns.hamtaro.space.
IN NS ns6.gandi.net.
IN MX 100 ns.hamtaro.space.

ns IN A 193.48.57.166
www IN A 193.48.57.166

</pre>

Modification du fichier :
<pre>
/etc/bind/named.conf.local
</pre>

<pre>
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "hamtaro.space" IN {
type master;
file "/etc/bind/db.hamtaro.space";
allow-transfer {217.70.177.40;};
};
</pre>

On va ensuite sur le site de Gandi pour modifier des informations.
Les Glue Records :
<pre>
'Nom du serveur' : ns.hamtaro.space
'IP' : 193.48.57.166
</pre>

Puis dans la rubrique modifier les serveurs DNS :
<pre>
'DNS1' : ns.hamtaro.space
'DNS2' : ns6.gandi.net
</pre>

Sécurisation de site web par certificat :

On tape la commande :
<pre>
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hamtaro.space.key -out hamtaro.space.csr
</pre>

Puis on remplis les champs demandés :
<pre>
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:hamtaro.space
</pre>

On se rend ensuite sur le site de Gandi et on rentre le contenu du fichier hamtaro.space.csr dans le champs CSR prévu à cet effet puis nous attendons la validation de notre certificat.

===== Configuration routeur=====
Configuration IPV6 des Vlan:
<pre>
ipv6 enable
ipv6 address 2001:660:4401:60XX::/64 eui-64
ipv6 nd prefix 2001:660:4401:60XX::/64 1000 900
</pre>

Avec les valeurs de XX variant de B0 à BA.
Pour le vlan130, cette valeur change : AA.

Interconnexion IPV4:
<pre>
router ospf 1
router-id 10.60.2.2
summary-address 10.60.0.0 255.255.0.0
summary-address 193.48.57.160 255.255.255.240
redistribute connected metric 30 subnets
network 192.168.222.0 0.0.0.7 area 1
</pre>

Interconnexion IPV6:
<pre>
ipv6 router rip tpima5sc
redistribute connected metric 1
redistribute static metric 1
redistribute rip 1 metric 1
</pre>

Une fois cela effectué, il faut que le vlan d'interconnexion prenne en compte ces modifications, il faut donc ajouter la commande :
<pre>
ipv6 rip tpima5sc enable
</pre>
Enfin, pour confirmer la configuration effectuée, nous affichons la table de routage ipv6 :
sh ipv6 route

On obtient alors le résultat suivant :
<pre>
IPv6 Routing Table - Default - 65 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, D - EIGRP, EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R ::/0 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:60::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6000::/56 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6002::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6003::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6004::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6005::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6006::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6007::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6008::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6009::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6011::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6013::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6014::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6015::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6016::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
...
</pre>

On essaie ensuite de ping le site de google depuis la machine virtuelle. On obtient un résultat positif. Notre configuration est donc fonctionnelle.

===== Sécurisation du réseau par HSRP =====
Pour empêcher les pertes de transmission de paquets, il faut ajouter une passerelle sur chaque interface.
De plus il faut ajouter l'adresse du routeur virtuel sur le vlan des machines virtuelles à savoir : 193.48.57.173.
On a alors :
<pre>
interface Vlan12
ip address 193.48.57.172 255.255.255.240
standby 1 ip 193.48.57.173
standby 1 priority 110
standby 1 preempt
</pre>

Une fois cela effectué sur notre routeur mais aussi sur le routeur de Stéphane et Thomas (groupe 5), nous réussissons à pinger leurs interfaces virtuelles ainsi que les interfaces de la machine virtuelle.
Nous pouvons également voir lors de l'affichage de la configuration en standby que notre routeur est considéré comme local tandis que le leur est en standby. La ligne traitant de la priorité fonctionne donc et permet la redondance du système.

===Réalisation 6ème semaine ===
====Suite Sécurisation SSL====
Après avoir obtenu notre certificat SSL sur le site GANDI, nous pouvons copier les fichiers utiles dans le dossier ssl:
<pre>
root@Flash:/etc/bind# cp certificat.crt /etc/ssl/certs/hamtaro.space.crt
root@Flash:/etc/bind# cp hamtaro.space.key /etc/ssl/private/hamtaro.space.key
root@Flash:/etc/bind# cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem
</pre>

Nous créons le fichier 000-hamtaro.space-ssl.conf dans le dossier "apache2/sites-available" afin de pouvoir joindre notre nom de serveur et Apache:
<pre>
#NameVirtualHost *:443
<VirtualHost 193.48.57.166:443>
ServerName www.hamtaro.space
ServerAlias hamtaro.space
DocumentRoot /var/www/www.hamtaro.space/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/hamtaro.space.crt
SSLCertificateKeyFile /etc/ssl/private/hamtaro.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem
SSLVerifyClient None
</VirtualHost>
<Directory /var/www/www.hamtaro.space>
Require all granted
</Directory>
ServerName "hamtaro.space"
</pre>

Enfin, nous devons modifier le fichier ports.conf afin que le serveur Apache écoute sur le port 443.
<pre>
Listen 80 443

<IfModule ssl_module>
Listen 443
</IfModule>

#<IfModule mod_gnutls.c>
# Listen 443
#</IfModule>

#<IfModule mod_ssl.c>
# Listen 443
#NameVirtualHost *:443
#</IfModule>
</pre>

Nous pouvons désormais activer le module SSL de apache :
<pre>a2enmod ssl</pre>

Puis nous pouvons activer notre certificat pour notre site :
<pre>
a2ensite 000-hamtaro.space-ssl.conf
Enabling site 000-hamtaro.space-ssl.
service apache2 reload //afin de charger la nouvelle configuration.
</pre>

Nous pouvons donc maintenant voir que notre site est sécurisé en allant sur https://www.hamtaro.space 
Il y a en effet le cadenas vert symbolisant cela:

[[Fichier:Screensecuresite.png]]

====Sécurisation par DNSSEC====

Dans un premier temps on va modifier le fichier /etc/bind/named.conf.options et rajouter la ligne :
<pre>
dnssec-enable yes
</pre>

Nous devons maintenant générer les clés (fichiers KSK et ZSK) que nous utiliserons afin de signer les zones:
<pre>
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hamtaro.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hamtaro.space
</pre>

Nous les plaçons dans un dossier nommé hamtaro.space.dnssec.

Nous modifions ensuite le fichier db.hamtaro.space afin d'inclure ces deux clés:
<pre>
$include /etc/bind/hamtaro.space.dnssec/hamtaro.space-ksk.key
$include /etc/bind/hamtaro.space.dnssec/hamtaro.space-zsk.key
</pre>

Il nous faut maintenant signer la zone :
<pre> dnssec-signzone -o hamtaro.space -k hamtaro.space-ksk ../db.hamtaro.space hamtaro.space-zsk
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.hamtaro.space.signed
</pre>

Nous ajoutons ensuite le DNSSEC sur Gandi :
[[Fichier:dnssecKadoc.png]]

On peut ensuite vérifier que notre DNSSEC est bien sécurisé :
<pre>
root@Kadoc:/etc/bind# dig DNSKEY hamtaro.space @localhost

; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> DNSKEY hamtaro.space @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5615
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;hamtaro.space. IN DNSKEY

;; AUTHORITY SECTION:
hamtaro.space. 604800 IN SOA ns.hamtaro.space. root.hamtaro.space.hamtaro.space. 3 604800 86400 2419200 604800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 28 13:21:10 CET 2016
;; MSG SIZE rcvd: 100

</pre>

====Partition RAID5====
Pour assurer la sécurisation des données, nous configurons trois partitions de volumes logiques sur la machine virtuelle:

<pre>
lvcreate -L 1G -n /dev/virtual/ima5-lapoulette
lvcreate -L 1G -n /dev/virtual/ima5-Karadoc
lvcreate -L 1G -n /dev/virtual/ima5-pelinord
</pre>

Puis nous modifions le fichier de configuration de notre machine virtuelle :
<pre>
disk = [
'file:/usr/local/xen/domains/Kadoc/disk.img,xvda2,w',
'file:/usr/local/xen/domains/Kadoc/swap.img,xvda1,w',
'phy:/dev/virtual/ima5-pelinord,xvdb,w',
'phy:/dev/virtual/ima5-Karadoc,xvdc,w',
'phy:/dev/virtual/ima5-lapoulette,xvdd,w',
]
</pre>

Nous pouvons maintenant relancer notre machine virtuelle.
Nous pouvons y créer le RAID5 avec les 3 partitions:
<pre> mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdb /dev/xvdc /dev/xvdd </pre>

On peut ensuite voir le détail de la configuration :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 12:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Nov 29 13:18:04 2016
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : 90156134:39a740fa:0de8c29d:486dce2c
Events : 22

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
1 202 32 1 active sync /dev/xvdc
3 202 48 2 active sync /dev/xvdd
</pre>

Nous devons ensuite sauvegarder cette configuration afin de garder notre md0, pour cela:
<pre> mdadm --detail --scan >> /etc/mdadm/mdadm.conf </pre>
puis nous pouvons copier les données sur le RAID5:
<pre>
root@Kadoc:~# mkfs /dev/md0
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 523776 4k blocks and 131072 inodes
Filesystem UUID: 2703e116-ed2c-46fe-964a-928be0b34cd6
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
</pre>
Puis:
<pre>
root@Kadoc:~# mount /dev/md0 /mnt
[ 702.230079] EXT4-fs (md0): mounting ext2 file system using the ext4 subsystem
[ 702.309734] EXT4-fs (md0): mounted filesystem without journal. Opts: (null)
</pre>

Nous allons maintenant voir ce qu'il se passe lorsque l'on enlève une des partitions à la machine.
Nous redémarrons la machine virtuelle et nous affichons le détail :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 12:23:50 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Tue Nov 29 12:43:56 2016
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : b333670e:27b24fbe:045a7e98:c7eafb49
Events : 14

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
2 0 0 2 removed
2 202 48 2 active sync /dev/xvdd
</pre>

Nous voyons donc bien qu'une partition a été enlevée.
Pour réparer cela,
<pre>
mdadm --set-faulty /dev/md0 /dev/xvdc
mdadm --remove /dev/md0 /dev/xvdc
</pre>

La partition est bien supprimée:
<pre>
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdb[0] xvdd[3]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
</pre>

On remet la partition:
<pre>mdadm --add /dev/md0 /dev/xvdc</pre>

On peut ensuite suivre l'avancement de la restauration:
<pre>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===========>.........] recovery = 56.9% (596964/1047552) finish=0.2min speed=29848K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=============>.......] recovery = 66.9% (701992/1047552) finish=0.1min speed=29249K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===============>.....] recovery = 75.0% (786728/1047552) finish=0.1min speed=29138K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=================>...] recovery = 85.1% (892660/1047552) finish=0.0min speed=29755K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 99.6% (1044732/1047552) finish=0.0min speed=30465K/sec

unused devices: <none>
root@Kadoc:/dev# [ 156.292138] md: md0: recovery done.
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>
</pre>

Enfin, on retrouve la configuration initiale :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Nov 29 13:18:04 2016
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : 90156134:39a740fa:0de8c29d:486dce2c
Events : 22

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
1 202 32 1 active sync /dev/xvdc
3 202 48 2 active sync /dev/xvdd
</pre>

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

Pour cette partie, nous commençons par installer lvm2, Gparted ainsi que cryptsetup sur notre eeePc.
Nous voulons une seule partition sur la carte SD. Pour cela on utilise:
<pre>
fdisk /dev/mmcblk1
</pre>
On créé alors une partition primaire sur tout l'espace disponible de la carte.

Une fois cette partition créée, elle n'est pas cryptée, nous allons donc maintenant utiliser le cryptsetup:

<pre>
cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
</pre>
Cette commande permet de formatter la partition au type Luks avec un chiffrement AES avec un algorithme de hâchage SHA256.
On doit aussi choisir un mot de passe pour crypter la partition.

Pour voir l'état du conteneur, on peut utiliser la commande :
<pre>
root@lamproie:~# cryptsetup luksDump /dev/mmcblk1
LUKS header information for /dev/mmcblk1

Version: 1
Cipher name: aes
Cipher mode: cbc-plain
Hash spec: sha256
Payload offset: 4096
MK bits: 256
MK digest: b9 ed bc f9 68 3c ac 64 d4 3b a4 44 5b 48 38 b2 d1 b4 7d 87
MK salt: 8a a5 f6 38 a7 08 fe 6b 90 7d 88 79 10 fc 70 15
95 e0 67 82 ee 34 fe 87 23 3e 2a 77 f7 ed cf 35
MK iterations: 125750
UUID: 07082d69-6117-42f8-81a3-695d1ea8e5df

Key Slot 0: ENABLED
Iterations: 1007873
Salt: 98 b5 bd 00 ca 5b 70 81 62 50 8d 5f ba ea d9 4c
35 38 70 bf 09 0b da 95 51 cb 81 c0 35 2d fe da
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
</pre>

On ouvre ensuite notre partition cryptée:
<pre> cryptsetup luksOpen /dev/mmcblk1 kadoc </pre>

On peut ainsi ajouter le système de fichiers à notre partition cryptée:
<pre>mkfs.ext3 /dev/mapper/kadoc</pre>

Ensuite, nous pouvons monter la partition pour pouvoir y écrire. Nous pouvons aussi la démonter lorsque nos fichiers seront copiés:
<pre>
mount -t ext3 /dev/mapper/kadoc /mnt/ //pour monter la partition.

umount /mnt/ //pour démonter la partition.
</pre>

Enfin pour encrypter à nouveau cette partition, on utilise la commande:
<pre> cryptsetup luksClose kadoc </pre>

On utilise la commande <pre> gparted /dev/mmcblk1 </pre> afin de voir la partition, on obtient ceci:

[[Fichier:Screencrypt.png]]

On voit donc que les informations de cette partition ne sont pas disponibles à moins d'avoir la clé.

===Réalisation 7ème semaine ===
Lors de cette semaine nous avons pu connecter le points d'accès Wifi de Valentin et Alexandre sur le commutateur de la salle E304. Pour cela, nous avons dû configurer un vlan1 sur le routeur qui prend l'adresse 10.60.1.3.
Ainsi, nous avons pu nous trouver ce point d'accès qui a pris l'adresse 10.60.1.6.
Nous avions ainsi les deux points d'accès qui étaient connectés dans chaque salle :
En E304 : avec l'adresse 10.60.1.6 et en E306 : 10.60.1.2.

Une fois cela fait, nous pouvons passer à la sécurisation Wifi par WPA2-EAP.

=====Sécurisation Wifi par WPA2-EAP=====
Nous allons utiliser cette méthode afin de créer le point d'accès que nous avons mentionné plus haut et d'en sécuriser la connexion.
Tout d'abord, nous devons créer le serveur FreeRadius:
Nous devons tout d'abord modifier certains fichiers de configuration du serveur :
dans le fichier ''eap.conf'' nous devons modifier une ligne afin de modifier le protocole d'identification :
<pre> default_eap_type = peap </pre>

Une fois cela fait, nous devons modifier le fichier ''clients.conf'', ce qui nous permettra de configurer nos points d'accès Wifi:
<pre>

client E304 {
ipaddr = 10.60.1.6
secret = kadoc
shortname = wifi1
}

client E306 {
ipaddr = 10.60.1.2
secret = kadoc
shortname = wifi2
}
</pre>
Nous avons ainsi configuré les deux points d'accès.

Enfin, nous devons ajouter une ligne au fichier users qui va nous permettre de créer un nouvel utilisateur pour l'identification:
<pre> karadoc Cleartext-Password := "perceval" </pre>

Une fois cela fait, nous pouvons lancer notre serveur FreeRadius.

Nous allons maintenant passer à la configuration du point d'accès afin d'avoir un accès sécurisé avec notre serveur précédemment détaillé:
<pre>
telnet 10.60.1.6

...

conf t

aaa new-model
aaa authentication login eap_kadoc group radius_kadoc
radius-server host 193.48.57.166 auth-port 1812 acct-port 1813 key kadoc
aaa group server radius radius_kadoc
server 193.48.57.166 auth-port 1812 acct-port 1813

exit

dot11 ssid SSID_KADOC
vlan 7
authentication open eap eap_kadoc
authentication network-eap eap_kadoc
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 7 mode ciphers aes-ccm tkip
ssid SSID_KADOC

exit

interface Dot11Radio0.7
encapsulation dot1Q 7
no ip route-cache
bridge-group 7
bridge-group 7 subscriber-loop-control
bridge-group 7 spanning-disabled
bridge-group 7 block-unknown-source
no bridge-group 7 source-learning
no bridge-group 7 unicast-flooding

exit

interface GigabitEthernet0.7
encapsulation dot1Q 7
bridge-group 7

exit

exit

write
</pre>

La borne est maintenant configurée, il ne nous reste plus qu'à nous y connecter.

Pour cela, nous devons encore modifier le wlan0 de l'eeepc.
Nous modifions donc le fichier /etc/network/interfaces :
<pre>
auto wlan0
iface wlan0 inet static
address 10.60.7.7
netmask 255.255.255.0
gateway 10.60.7.1
wpa-ssid KADOC
wpa-key-mgmt WPA-EAP
wpa-identity karadoc
wpa-password perceval
</pre>

Une fois cela fait, nous pouvons nous connecter sur le point d'accès de la salle E304. Pour se connecter sur celui de la E306, il faudrait faire la même configuration sur ce point d'accès.
Nous avons réussi à nous connecter à ce point d'accès en rentrant une adresse IP valide à la main. Pour rendre cela automatique, nous devrons installer un serveur DHCP sur notre Eeepc qui nous permettre d'attribuer une adresse IP à notre smartphone
Une fois notre serveur DHCP installé et correctement configuré, nous pouvons nous connecter comme prévu sans avoir à rentrer une adresse IP "à la main".

[[Fichier:KadocConnected.png||200px||center]]

===Réalisation 9ème semaine ===

Nous avons dans un premier temps installer Asterisk
<pre>
apt-get install asterisk
</pre>

Nous avons ensuite configuré le fichier <pre> /etc/asterisk/users.conf </pre> en y ajoutant :
<pre>
[general]
hasvoicemail = yes
hassip = yes
hasiax = yes
callwaiting = yes
threewaycalling = yes
callwaitingcallerid = yes
transfer = yes
canpark = yes
cancallforward = yes
callreturn = yes
callgroup = 1
pickupgroup = 1
nat = yes

[6001]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = kadoc
username = heykadoc
secret = perceval
context = work

[6002]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = karadoc
username = heykaradoc
secret = perceval
context = work
</pre>

Ensuite, on ajoute dans le fichier <pre>/etc/asterisk/extensions.conf :</pre>
<pre>
[work]
exten => _6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()
</pre>

On restart ensuite asterisk :
<pre>
service asterisk restart
</pre>

Puis on reload l'ensemble des fichiers afin qu'ils soient pris en compte :
<pre>
reload
</pre>

On cherche maintenant à savoir si notre configuration fonctionne. Pour cela, nous installons l'application CSipSimple sur deux téléphones Android sur lesquels nous configurons deux comptes.

Lorsque nous essayons de nous appeler, nous voyons que la communication fonctionne:
[[Fichier:15497641_10210148661905836_1314328693_n.jpg||400px||center]]

Cahier 2016 groupe n°6

2017-01-03T14:11:50Z

Rlentieu : /* Présentation du travail */

== Cahier des charges ==
=== Présentation du travail ===
[[Fichier:Travail.jpeg||600px||center]]
==== Répartition du travail ====

{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/10)
| Connaissances du TP/ Recherche sur le routeur 3560E / Installation de la machine virtuelle
|-
! scope="row" | Séance 2 (10/10)
| Création des VLAN
|-
! scope="row" | Séance 3 (13/10)
| Création des VLAN / Création de la machine virtuelle
|-
! scope="row" | Séance 4 (24/10)
| Crackage de clé WEP
|-
! scope="row" | Séance 5 (07/11)
| Configuration Eeepc / Crackage clé WPA / Test de la configuration locale
|-
! scope="row" | Séance 6 (14/11)
| Configuration machine virtuelle / Configuration routeur ipv6 / interconnexion ipv4 et ipv6 / HSRP
|-
! scope="row" | Séance 7 (28/11)
| Configuration machine Virtuelle SSL / DNSSEC / Partition RAID5 / Cryptage des données
|-
! scope="row" | Séance 8 (05/12)
| Configuration Routeur pour Point d'Accès WIFI / Sécurisation Wifi par WPA2-EAP
|-
! scope="row" | Séance 9 (12/12)
| Configuration Asterisk et test de la VoIP
|}

===Réalisation 1ère semaine ===

Pour la première séance nous nous sommes chargés d'installer la machine virtuelle Xen à l'aide de la commande :
<pre>
xen-create-image --hostname=Kadoc --ip=193.48.57.166 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --gateway=193.48.57.172
--netmask=255.255.255.240 --dir=/usr/local/xen --passwd
</pre>
Ainsi, nous obtenons ce résultat:
<pre>
Installation Summary
---------------------
Hostname : Kadoc
Distribution : jessie
MAC Address : 00:16:3E:60:01:B1
IP Address(es) : 193.48.57.166
RSA Fingerprint : cf:03:35:4e:b7:f1:d4:f5:52:a1:d7:52:63:5d:83:57
Root Password : N/A
</pre>

===Réalisation 2ème semaine ===
=====VLANs=====
Durant les deux séances de cette semaine, nous avons réalisé la configuration locale du routeur 3560E, notamment la configuration des VLANs.

Pour cela, nous avons utilisé la communication série.
Lors du démarrage, nous devons le configurer :
<pre>
conf t
hostname Perceval
enable secret pasglop
</pre>

Nous passons maintenant à la configuration des VLANs:

Nous avons 11 VLANs à configurer :
* VLAN2 à VLAN11 : un pour chaque groupe
* VLAN12 : pour les machines virtuelles et donc le lien entre Cordouan et les commutateurs
* VLAN13 : pour l'interconnexion, c'est à dire le lien entre notre routeur et le routeur de l'école.

Pour la configuration, nous prendrons l'exemple du vlan 2.
Tout d'abord, nous affectons aux VLANs utiles:
<pre>
vlan 2
name Vlan2
exit
</pre>

Une fois le nom affecté :
<pre>
conf t
int Vlan2
ip address 10.60.2.2 255.255.255.0
exit
</pre>

=====Machine virtuelle=====

Tout d'abord, nous nous connectons sur le serveur cordouan:
<pre>
ssh root@cordouan.insecserv.deule.net
</pre>

Nous créons ensuite la machine avec tous les renseignements souhaités
<pre>
xen-create-image --hostname=Kadoc --ip=193.48.57.166 --netmask=255.255.255.240 --gateway=193.48.57.172
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie
</pre>
Enfin on démarre la machine virtuelle
<pre>
xl create /etc/xen/Kadoc.cfg
</pre>
Puis nous la lançons
<pre>
xl console Kadoc
</pre>

Lors de cette séance, nous avons aussi réservé notre nom de domaine sur Gandi : hamtaro.space

Nous avons également modifier le fichier de configuration de la VM en modifiant le fichier "/etc/xen/Kadoc.cfg" pour la taille mémoire 'de 128 à 512MB" ainsi que pour ajouter le bridge IMA5sc.

===Réalisation 3ème semaine ===
=====crackage clé WEP=====
1ere commande : airodump-ng --encrypt wep wlan2
BSSID PWR Beacons #data #/s CH MB ENC CIPHER AUTH ESSID
04:DA:D2:9C:50:56 -57 1 65 32 2 54e. WEP WEP cracotte07

La cible que nous avons choisie est "cracotte07", donc on utilise la commande suivante :

airodump-ng --essid cracotte07 --channel 2 -w testcrack wlan2

On obtient:

CH 2 ][ Elapsed: 3 mins ][ 2014-12-12 18:15
<pre>
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
04:DA:D2:9C:50:56 -55 6 505 9516 231 2 54e. WEP WEP cracotte07
</pre>
Le monitoring est donc lancé, nous pouvons passer au crackage :
aircrack-ng testcrack-01.cap

On obtient finalement la clé :

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:E4:44:44:44 ]
Decrypted correctly: 100%

===Réalisation 4ème semaine===

=====Configuration eeePC =====
''SSH:''

On modifie le fichier /etc/resolv.conf
<pre>
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
</pre>

Pour pouvoir se connecter en ssh il est nécessaire de modifier le ficher /etc/network/interfaces de la façon suivante :
rajouter les lignes :
<pre>
auto wlan2
iface wlan2 inet static
wireless mode-managed
wireless essid Wolverine // pour se connecter à la borne Wifi
wireless-key 0123456789 // mot de passe de la borne
address 172.26.79.22 // notre adresse
netmask 255.255.255.240
gateway 172.26.79.254
</pre>

''Intrusion par changement d'adresse MAC''
En changeant notre adresse MAC grâce à la commande
<pre>
ifconfig wlan2 down
ifconfig wlan2 hw ether 74:29:af:f3:fd:71
ifconfig wlan2 up
</pre>
On ne peut plus se connecter.

=====Crackage clé WPA=====

On effectue la même démarche que pour le crackage de la clé WEP pour :
<pre>
airodump-ng --encrypt wpa wlan1
</pre>
On choisit de cracker cracotte03
<pre>
airodump-ng -w out --encrypt wpa -c 13 --bssid 04:DA:D2:9C:50:52 wlan1
</pre>
On obtient le handshake 04:DA:D2:9C:50:52

On crée le dictionnaire grâce à la commande :
<pre>
crunch 8 8 0123456789 > dico.txt
</pre>
On lance ensuite :
<pre>
airodump-ng --essid cracotte03 -c 13 --bssid 04:DA:D2:9C:50:52 -w dump wlan1
</pre>
On décode ensuite le fichier dump grâce à la commande :
<pre>
aircrack-ng dump-01.cap -w dico.txt -l KEY
</pre>
Après un long moment on obtient le résultat, la clé WPA est
<pre>
12399903
</pre>

=====Test configuration routeur=====
Pour tester la configuration de notre routeur, il fallait le relier au commutateur qui devait être relié au serveur cordouan.
Or pour cela, il nous était impossible de le relier en filaire. Nous avons donc utilisé la fibre.
Nous avons donc dû utiliser un convertisseur de l'interface 10Gi en deux interfaces Gi.
Une fois cela effectué, nous pouvions relier la fibre au commutateur qui était lui-même relié au serveur Cordouan.
Il fallait seulement changer le mode access du port sur le commutateur et le configurer en Trunk.

Une fois cela effectué et bien configuré, nous parvenons à "pinger" notre routeur depuis notre machine virtuelle.

<pre>
# ping 193.48.57.172
PING 193.48.57.172 (193.48.57.172) 56(84) bytes of data.
64 bytes from 193.48.57.172: icmp_seq=1 ttl=255 time=6.23 ms
64 bytes from 193.48.57.172: icmp_seq=2 ttl=255 time=1.01 ms
64 bytes from 193.48.57.172: icmp_seq=3 ttl=255 time=19.8 ms
64 bytes from 193.48.57.172: icmp_seq=4 ttl=255 time=1.56 ms
64 bytes from 193.48.57.172: icmp_seq=5 ttl=255 time=8.55 ms
64 bytes from 193.48.57.172: icmp_seq=6 ttl=255 time=2.36 ms
^C
--- 193.48.57.172 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 1.018/6.593/19.818/6.495 ms
</pre>

===Réalisation 5ème semaine ===

=====Configuration machine virtuelle=====
Installation des packages ssh, apache2 et bind9.

Modification du fichier :
<pre>
/etc/bind/db.hamtaro.space
</pre>

<pre>
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hamtaro.space. root.hamtaro.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN NS ns.hamtaro.space.
IN NS ns6.gandi.net.
IN MX 100 ns.hamtaro.space.

ns IN A 193.48.57.166
www IN A 193.48.57.166

</pre>

Modification du fichier :
<pre>
/etc/bind/named.conf.local
</pre>

<pre>
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "hamtaro.space" IN {
type master;
file "/etc/bind/db.hamtaro.space";
allow-transfer {217.70.177.40;};
};
</pre>

On va ensuite sur le site de Gandi pour modifier des informations.
Les Glue Records :
<pre>
'Nom du serveur' : ns.hamtaro.space
'IP' : 193.48.57.166
</pre>

Puis dans la rubrique modifier les serveurs DNS :
<pre>
'DNS1' : ns.hamtaro.space
'DNS2' : ns6.gandi.net
</pre>

Sécurisation de site web par certificat :

On tape la commande :
<pre>
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hamtaro.space.key -out hamtaro.space.csr
</pre>

Puis on remplis les champs demandés :
<pre>
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:hamtaro.space
</pre>

On se rend ensuite sur le site de Gandi et on rentre le contenu du fichier hamtaro.space.csr dans le champs CSR prévu à cet effet puis nous attendons la validation de notre certificat.

===== Configuration routeur=====
Configuration IPV6 des Vlan:
<pre>
ipv6 enable
ipv6 address 2001:660:4401:60XX::/64 eui-64
ipv6 nd prefix 2001:660:4401:60XX::/64 1000 900
</pre>

Avec les valeurs de XX variant de B0 à BA.
Pour le vlan130, cette valeur change : AA.

Interconnexion IPV4:
<pre>
router ospf 1
router-id 10.60.2.2
summary-address 10.60.0.0 255.255.0.0
summary-address 193.48.57.160 255.255.255.240
redistribute connected metric 30 subnets
network 192.168.222.0 0.0.0.7 area 1
</pre>

Interconnexion IPV6:
<pre>
ipv6 router rip tpima5sc
redistribute connected metric 1
redistribute static metric 1
redistribute rip 1 metric 1
</pre>

Une fois cela effectué, il faut que le vlan d'interconnexion prenne en compte ces modifications, il faut donc ajouter la commande :
<pre>
ipv6 rip tpima5sc enable
</pre>
Enfin, pour confirmer la configuration effectuée, nous affichons la table de routage ipv6 :
sh ipv6 route

On obtient alors le résultat suivant :
<pre>
IPv6 Routing Table - Default - 65 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, D - EIGRP, EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R ::/0 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:60::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6000::/56 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6002::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6003::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6004::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6005::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6006::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6007::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6008::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6009::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6011::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6013::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6014::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6015::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6016::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
...
</pre>

On essaie ensuite de ping le site de google depuis la machine virtuelle. On obtient un résultat positif. Notre configuration est donc fonctionnelle.

===== Sécurisation du réseau par HSRP =====
Pour empêcher les pertes de transmission de paquets, il faut ajouter une passerelle sur chaque interface.
De plus il faut ajouter l'adresse du routeur virtuel sur le vlan des machines virtuelles à savoir : 193.48.57.173.
On a alors :
<pre>
interface Vlan12
ip address 193.48.57.172 255.255.255.240
standby 1 ip 193.48.57.173
standby 1 priority 110
standby 1 preempt
</pre>

Une fois cela effectué sur notre routeur mais aussi sur le routeur de Stéphane et Thomas (groupe 5), nous réussissons à pinger leurs interfaces virtuelles ainsi que les interfaces de la machine virtuelle.
Nous pouvons également voir lors de l'affichage de la configuration en standby que notre routeur est considéré comme local tandis que le leur est en standby. La ligne traitant de la priorité fonctionne donc et permet la redondance du système.

===Réalisation 6ème semaine ===
====Suite Sécurisation SSL====
Après avoir obtenu notre certificat SSL sur le site GANDI, nous pouvons copier les fichiers utiles dans le dossier ssl:
<pre>
root@Flash:/etc/bind# cp certificat.crt /etc/ssl/certs/hamtaro.space.crt
root@Flash:/etc/bind# cp hamtaro.space.key /etc/ssl/private/hamtaro.space.key
root@Flash:/etc/bind# cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem
</pre>

Nous créons le fichier 000-hamtaro.space-ssl.conf dans le dossier "apache2/sites-available" afin de pouvoir joindre notre nom de serveur et Apache:
<pre>
#NameVirtualHost *:443
<VirtualHost 193.48.57.166:443>
ServerName www.hamtaro.space
ServerAlias hamtaro.space
DocumentRoot /var/www/www.hamtaro.space/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/hamtaro.space.crt
SSLCertificateKeyFile /etc/ssl/private/hamtaro.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem
SSLVerifyClient None
</VirtualHost>
<Directory /var/www/www.hamtaro.space>
Require all granted
</Directory>
ServerName "hamtaro.space"
</pre>

Enfin, nous devons modifier le fichier ports.conf afin que le serveur Apache écoute sur le port 443.
<pre>
Listen 80 443

<IfModule ssl_module>
Listen 443
</IfModule>

#<IfModule mod_gnutls.c>
# Listen 443
#</IfModule>

#<IfModule mod_ssl.c>
# Listen 443
#NameVirtualHost *:443
#</IfModule>
</pre>

Nous pouvons désormais activer le module SSL de apache :
<pre>a2enmod ssl</pre>

Puis nous pouvons activer notre certificat pour notre site :
<pre>
a2ensite 000-hamtaro.space-ssl.conf
Enabling site 000-hamtaro.space-ssl.
service apache2 reload //afin de charger la nouvelle configuration.
</pre>

Nous pouvons donc maintenant voir que notre site est sécurisé en allant sur https://www.hamtaro.space 
Il y a en effet le cadenas vert symbolisant cela:

[[Fichier:Screensecuresite.png]]

====Sécurisation par DNSSEC====

Dans un premier temps on va modifier le fichier /etc/bind/named.conf.options et rajouter la ligne :
<pre>
dnssec-enable yes
</pre>

Nous devons maintenant générer les clés (fichiers KSK et ZSK) que nous utiliserons afin de signer les zones:
<pre>
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hamtaro.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hamtaro.space
</pre>

Nous les plaçons dans un dossier nommé hamtaro.space.dnssec.

Nous modifions ensuite le fichier db.hamtaro.space afin d'inclure ces deux clés:
<pre>
$include /etc/bind/hamtaro.space.dnssec/hamtaro.space-ksk.key
$include /etc/bind/hamtaro.space.dnssec/hamtaro.space-zsk.key
</pre>

Il nous faut maintenant signer la zone :
<pre> dnssec-signzone -o hamtaro.space -k hamtaro.space-ksk ../db.hamtaro.space hamtaro.space-zsk
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.hamtaro.space.signed
</pre>

Nous ajoutons ensuite le DNSSEC sur Gandi :
[[Fichier:dnssecKadoc.png]]

On peut ensuite vérifier que notre DNSSEC est bien sécurisé :
<pre>
root@Kadoc:/etc/bind# dig DNSKEY hamtaro.space @localhost

; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> DNSKEY hamtaro.space @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5615
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;hamtaro.space. IN DNSKEY

;; AUTHORITY SECTION:
hamtaro.space. 604800 IN SOA ns.hamtaro.space. root.hamtaro.space.hamtaro.space. 3 604800 86400 2419200 604800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 28 13:21:10 CET 2016
;; MSG SIZE rcvd: 100

</pre>

====Partition RAID5====
Pour assurer la sécurisation des données, nous configurons trois partitions de volumes logiques sur la machine virtuelle:

<pre>
lvcreate -L 1G -n /dev/virtual/ima5-lapoulette
lvcreate -L 1G -n /dev/virtual/ima5-Karadoc
lvcreate -L 1G -n /dev/virtual/ima5-pelinord
</pre>

Puis nous modifions le fichier de configuration de notre machine virtuelle :
<pre>
disk = [
'file:/usr/local/xen/domains/Kadoc/disk.img,xvda2,w',
'file:/usr/local/xen/domains/Kadoc/swap.img,xvda1,w',
'phy:/dev/virtual/ima5-pelinord,xvdb,w',
'phy:/dev/virtual/ima5-Karadoc,xvdc,w',
'phy:/dev/virtual/ima5-lapoulette,xvdd,w',
]
</pre>

Nous pouvons maintenant relancer notre machine virtuelle.
Nous pouvons y créer le RAID5 avec les 3 partitions:
<pre> mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdb /dev/xvdc /dev/xvdd </pre>

On peut ensuite voir le détail de la configuration :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 12:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Nov 29 13:18:04 2016
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : 90156134:39a740fa:0de8c29d:486dce2c
Events : 22

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
1 202 32 1 active sync /dev/xvdc
3 202 48 2 active sync /dev/xvdd
</pre>

Nous devons ensuite sauvegarder cette configuration afin de garder notre md0, pour cela:
<pre> mdadm --detail --scan >> /etc/mdadm/mdadm.conf </pre>
puis nous pouvons copier les données sur le RAID5:
<pre>
root@Kadoc:~# mkfs /dev/md0
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 523776 4k blocks and 131072 inodes
Filesystem UUID: 2703e116-ed2c-46fe-964a-928be0b34cd6
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
</pre>
Puis:
<pre>
root@Kadoc:~# mount /dev/md0 /mnt
[ 702.230079] EXT4-fs (md0): mounting ext2 file system using the ext4 subsystem
[ 702.309734] EXT4-fs (md0): mounted filesystem without journal. Opts: (null)
</pre>

Nous allons maintenant voir ce qu'il se passe lorsque l'on enlève une des partitions à la machine.
Nous redémarrons la machine virtuelle et nous affichons le détail :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 12:23:50 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Tue Nov 29 12:43:56 2016
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : b333670e:27b24fbe:045a7e98:c7eafb49
Events : 14

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
2 0 0 2 removed
2 202 48 2 active sync /dev/xvdd
</pre>

Nous voyons donc bien qu'une partition a été enlevée.
Pour réparer cela,
<pre>
mdadm --set-faulty /dev/md0 /dev/xvdc
mdadm --remove /dev/md0 /dev/xvdc
</pre>

La partition est bien supprimée:
<pre>
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdb[0] xvdd[3]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
</pre>

On remet la partition:
<pre>mdadm --add /dev/md0 /dev/xvdc</pre>

On peut ensuite suivre l'avancement de la restauration:
<pre>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===========>.........] recovery = 56.9% (596964/1047552) finish=0.2min speed=29848K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=============>.......] recovery = 66.9% (701992/1047552) finish=0.1min speed=29249K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===============>.....] recovery = 75.0% (786728/1047552) finish=0.1min speed=29138K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=================>...] recovery = 85.1% (892660/1047552) finish=0.0min speed=29755K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 99.6% (1044732/1047552) finish=0.0min speed=30465K/sec

unused devices: <none>
root@Kadoc:/dev# [ 156.292138] md: md0: recovery done.
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>
</pre>

Enfin, on retrouve la configuration initiale :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Nov 29 13:18:04 2016
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : 90156134:39a740fa:0de8c29d:486dce2c
Events : 22

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
1 202 32 1 active sync /dev/xvdc
3 202 48 2 active sync /dev/xvdd
</pre>

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

Pour cette partie, nous commençons par installer lvm2, Gparted ainsi que cryptsetup sur notre eeePc.
Nous voulons une seule partition sur la carte SD. Pour cela on utilise:
<pre>
fdisk /dev/mmcblk1
</pre>
On créé alors une partition primaire sur tout l'espace disponible de la carte.

Une fois cette partition créée, elle n'est pas cryptée, nous allons donc maintenant utiliser le cryptsetup:

<pre>
cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
</pre>
Cette commande permet de formatter la partition au type Luks avec un chiffrement AES avec un algorithme de hâchage SHA256.
On doit aussi choisir un mot de passe pour crypter la partition.

Pour voir l'état du conteneur, on peut utiliser la commande :
<pre>
root@lamproie:~# cryptsetup luksDump /dev/mmcblk1
LUKS header information for /dev/mmcblk1

Version: 1
Cipher name: aes
Cipher mode: cbc-plain
Hash spec: sha256
Payload offset: 4096
MK bits: 256
MK digest: b9 ed bc f9 68 3c ac 64 d4 3b a4 44 5b 48 38 b2 d1 b4 7d 87
MK salt: 8a a5 f6 38 a7 08 fe 6b 90 7d 88 79 10 fc 70 15
95 e0 67 82 ee 34 fe 87 23 3e 2a 77 f7 ed cf 35
MK iterations: 125750
UUID: 07082d69-6117-42f8-81a3-695d1ea8e5df

Key Slot 0: ENABLED
Iterations: 1007873
Salt: 98 b5 bd 00 ca 5b 70 81 62 50 8d 5f ba ea d9 4c
35 38 70 bf 09 0b da 95 51 cb 81 c0 35 2d fe da
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
</pre>

On ouvre ensuite notre partition cryptée:
<pre> cryptsetup luksOpen /dev/mmcblk1 kadoc </pre>

On peut ainsi ajouter le système de fichiers à notre partition cryptée:
<pre>mkfs.ext3 /dev/mapper/kadoc</pre>

Ensuite, nous pouvons monter la partition pour pouvoir y écrire. Nous pouvons aussi la démonter lorsque nos fichiers seront copiés:
<pre>
mount -t ext3 /dev/mapper/kadoc /mnt/ //pour monter la partition.

umount /mnt/ //pour démonter la partition.
</pre>

Enfin pour encrypter à nouveau cette partition, on utilise la commande:
<pre> cryptsetup luksClose kadoc </pre>

On utilise la commande <pre> gparted /dev/mmcblk1 </pre> afin de voir la partition, on obtient ceci:

[[Fichier:Screencrypt.png]]

On voit donc que les informations de cette partition ne sont pas disponibles à moins d'avoir la clé.

===Réalisation 7ème semaine ===
Lors de cette semaine nous avons pu connecter le points d'accès Wifi de Valentin et Alexandre sur le commutateur de la salle E304. Pour cela, nous avons dû configurer un vlan1 sur le routeur qui prend l'adresse 10.60.1.3.
Ainsi, nous avons pu nous trouver ce point d'accès qui a pris l'adresse 10.60.1.6.
Nous avions ainsi les deux points d'accès qui étaient connectés dans chaque salle :
En E304 : avec l'adresse 10.60.1.6 et en E306 : 10.60.1.2.

Une fois cela fait, nous pouvons passer à la sécurisation Wifi par WPA2-EAP.

=====Sécurisation Wifi par WPA2-EAP=====
Nous allons utiliser cette méthode afin de créer le point d'accès que nous avons mentionné plus haut et d'en sécuriser la connexion.
Tout d'abord, nous devons créer le serveur FreeRadius:
Nous devons tout d'abord modifier certains fichiers de configuration du serveur :
dans le fichier ''eap.conf'' nous devons modifier une ligne afin de modifier le protocole d'identification :
<pre> default_eap_type = peap </pre>

Une fois cela fait, nous devons modifier le fichier ''clients.conf'', ce qui nous permettra de configurer nos points d'accès Wifi:
<pre>

client E304 {
ipaddr = 10.60.1.6
secret = kadoc
shortname = wifi1
}

client E306 {
ipaddr = 10.60.1.2
secret = kadoc
shortname = wifi2
}
</pre>
Nous avons ainsi configuré les deux points d'accès.

Enfin, nous devons ajouter une ligne au fichier users qui va nous permettre de créer un nouvel utilisateur pour l'identification:
<pre> karadoc Cleartext-Password := "perceval" </pre>

Une fois cela fait, nous pouvons lancer notre serveur FreeRadius.

Nous allons maintenant passer à la configuration du point d'accès afin d'avoir un accès sécurisé avec notre serveur précédemment détaillé:
<pre>
telnet 10.60.1.6

...

conf t

aaa new-model
aaa authentication login eap_kadoc group radius_kadoc
radius-server host 193.48.57.166 auth-port 1812 acct-port 1813 key kadoc
aaa group server radius radius_kadoc
server 193.48.57.166 auth-port 1812 acct-port 1813

exit

dot11 ssid SSID_KADOC
vlan 7
authentication open eap eap_kadoc
authentication network-eap eap_kadoc
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 7 mode ciphers aes-ccm tkip
ssid SSID_KADOC

exit

interface Dot11Radio0.7
encapsulation dot1Q 7
no ip route-cache
bridge-group 7
bridge-group 7 subscriber-loop-control
bridge-group 7 spanning-disabled
bridge-group 7 block-unknown-source
no bridge-group 7 source-learning
no bridge-group 7 unicast-flooding

exit

interface GigabitEthernet0.7
encapsulation dot1Q 7
bridge-group 7

exit

exit

write
</pre>

La borne est maintenant configurée, il ne nous reste plus qu'à nous y connecter.

Pour cela, nous devons encore modifier le wlan0 de l'eeepc.
Nous modifions donc le fichier /etc/network/interfaces :
<pre>
auto wlan0
iface wlan0 inet static
address 10.60.7.7
netmask 255.255.255.0
gateway 10.60.7.1
wpa-ssid KADOC
wpa-key-mgmt WPA-EAP
wpa-identity karadoc
wpa-password perceval
</pre>

Une fois cela fait, nous pouvons nous connecter sur le point d'accès de la salle E304. Pour se connecter sur celui de la E306, il faudrait faire la même configuration sur ce point d'accès.
Nous avons réussi à nous connecter à ce point d'accès en rentrant une adresse IP valide à la main. Pour rendre cela automatique, nous devrons installer un serveur DHCP sur notre Eeepc qui nous permettre d'attribuer une adresse IP à notre smartphone
Une fois notre serveur DHCP installé et correctement configuré, nous pouvons nous connecter comme prévu sans avoir à rentrer une adresse IP "à la main".

[[Fichier:KadocConnected.png||200px||center]]

===Réalisation 9ème semaine ===

Nous avons dans un premier temps installer Asterisk
<pre>
apt-get install asterisk
</pre>

Nous avons ensuite configuré le fichier <pre> /etc/asterisk/users.conf </pre> en y ajoutant :
<pre>
[general]
hasvoicemail = yes
hassip = yes
hasiax = yes
callwaiting = yes
threewaycalling = yes
callwaitingcallerid = yes
transfer = yes
canpark = yes
cancallforward = yes
callreturn = yes
callgroup = 1
pickupgroup = 1
nat = yes

[6001]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = kadoc
username = heykadoc
secret = perceval
context = work

[6002]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = karadoc
username = heykaradoc
secret = perceval
context = work
</pre>

Ensuite, on ajoute dans le fichier <pre>/etc/asterisk/extensions.conf :</pre>
<pre>
[work]
exten => _6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()
</pre>

On restart ensuite asterisk :
<pre>
service asterisk restart
</pre>

Puis on reload l'ensemble des fichiers afin qu'ils soient pris en compte :
<pre>
reload
</pre>

On cherche maintenant à savoir si notre configuration fonctionne. Pour cela, nous installons l'application CSipSimple sur deux téléphones Android sur lesquels nous configurons deux comptes.

Lorsque nous essayons de nous appeler, nous voyons que la communication fonctionne:
[[Fichier:15497641_10210148661905836_1314328693_n.jpg||400px||center]]

Gant de Boxe connecté

2017-01-03T14:07:14Z

Rlentieu : /* Matériel utilisé */

Cahier 2016 groupe n°6

2017-01-03T14:03:01Z

Rlentieu : /* Réalisation 9ème semaine */

== Cahier des charges ==
=== Présentation du travail ===

==== Répartition du travail ====

{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/10)
| Connaissances du TP/ Recherche sur le routeur 3560E / Installation de la machine virtuelle
|-
! scope="row" | Séance 2 (10/10)
| Création des VLAN
|-
! scope="row" | Séance 3 (13/10)
| Création des VLAN / Création de la machine virtuelle
|-
! scope="row" | Séance 4 (24/10)
| Crackage de clé WEP
|-
! scope="row" | Séance 5 (07/11)
| Configuration Eeepc / Crackage clé WPA / Test de la configuration locale
|-
! scope="row" | Séance 6 (14/11)
| Configuration machine virtuelle / Configuration routeur ipv6 / interconnexion ipv4 et ipv6 / HSRP
|-
! scope="row" | Séance 7 (28/11)
| Configuration machine Virtuelle SSL / DNSSEC / Partition RAID5 / Cryptage des données
|-
! scope="row" | Séance 8 (05/12)
| Configuration Routeur pour Point d'Accès WIFI / Sécurisation Wifi par WPA2-EAP
|-
! scope="row" | Séance 9 (12/12)
| Configuration Asterisk et test de la VoIP
|}

===Réalisation 1ère semaine ===

Pour la première séance nous nous sommes chargés d'installer la machine virtuelle Xen à l'aide de la commande :
<pre>
xen-create-image --hostname=Kadoc --ip=193.48.57.166 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --gateway=193.48.57.172
--netmask=255.255.255.240 --dir=/usr/local/xen --passwd
</pre>
Ainsi, nous obtenons ce résultat:
<pre>
Installation Summary
---------------------
Hostname : Kadoc
Distribution : jessie
MAC Address : 00:16:3E:60:01:B1
IP Address(es) : 193.48.57.166
RSA Fingerprint : cf:03:35:4e:b7:f1:d4:f5:52:a1:d7:52:63:5d:83:57
Root Password : N/A
</pre>

===Réalisation 2ème semaine ===
=====VLANs=====
Durant les deux séances de cette semaine, nous avons réalisé la configuration locale du routeur 3560E, notamment la configuration des VLANs.

Pour cela, nous avons utilisé la communication série.
Lors du démarrage, nous devons le configurer :
<pre>
conf t
hostname Perceval
enable secret pasglop
</pre>

Nous passons maintenant à la configuration des VLANs:

Nous avons 11 VLANs à configurer :
* VLAN2 à VLAN11 : un pour chaque groupe
* VLAN12 : pour les machines virtuelles et donc le lien entre Cordouan et les commutateurs
* VLAN13 : pour l'interconnexion, c'est à dire le lien entre notre routeur et le routeur de l'école.

Pour la configuration, nous prendrons l'exemple du vlan 2.
Tout d'abord, nous affectons aux VLANs utiles:
<pre>
vlan 2
name Vlan2
exit
</pre>

Une fois le nom affecté :
<pre>
conf t
int Vlan2
ip address 10.60.2.2 255.255.255.0
exit
</pre>

=====Machine virtuelle=====

Tout d'abord, nous nous connectons sur le serveur cordouan:
<pre>
ssh root@cordouan.insecserv.deule.net
</pre>

Nous créons ensuite la machine avec tous les renseignements souhaités
<pre>
xen-create-image --hostname=Kadoc --ip=193.48.57.166 --netmask=255.255.255.240 --gateway=193.48.57.172
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie
</pre>
Enfin on démarre la machine virtuelle
<pre>
xl create /etc/xen/Kadoc.cfg
</pre>
Puis nous la lançons
<pre>
xl console Kadoc
</pre>

Lors de cette séance, nous avons aussi réservé notre nom de domaine sur Gandi : hamtaro.space

Nous avons également modifier le fichier de configuration de la VM en modifiant le fichier "/etc/xen/Kadoc.cfg" pour la taille mémoire 'de 128 à 512MB" ainsi que pour ajouter le bridge IMA5sc.

===Réalisation 3ème semaine ===
=====crackage clé WEP=====
1ere commande : airodump-ng --encrypt wep wlan2
BSSID PWR Beacons #data #/s CH MB ENC CIPHER AUTH ESSID
04:DA:D2:9C:50:56 -57 1 65 32 2 54e. WEP WEP cracotte07

La cible que nous avons choisie est "cracotte07", donc on utilise la commande suivante :

airodump-ng --essid cracotte07 --channel 2 -w testcrack wlan2

On obtient:

CH 2 ][ Elapsed: 3 mins ][ 2014-12-12 18:15
<pre>
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
04:DA:D2:9C:50:56 -55 6 505 9516 231 2 54e. WEP WEP cracotte07
</pre>
Le monitoring est donc lancé, nous pouvons passer au crackage :
aircrack-ng testcrack-01.cap

On obtient finalement la clé :

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:E4:44:44:44 ]
Decrypted correctly: 100%

===Réalisation 4ème semaine===

=====Configuration eeePC =====
''SSH:''

On modifie le fichier /etc/resolv.conf
<pre>
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
</pre>

Pour pouvoir se connecter en ssh il est nécessaire de modifier le ficher /etc/network/interfaces de la façon suivante :
rajouter les lignes :
<pre>
auto wlan2
iface wlan2 inet static
wireless mode-managed
wireless essid Wolverine // pour se connecter à la borne Wifi
wireless-key 0123456789 // mot de passe de la borne
address 172.26.79.22 // notre adresse
netmask 255.255.255.240
gateway 172.26.79.254
</pre>

''Intrusion par changement d'adresse MAC''
En changeant notre adresse MAC grâce à la commande
<pre>
ifconfig wlan2 down
ifconfig wlan2 hw ether 74:29:af:f3:fd:71
ifconfig wlan2 up
</pre>
On ne peut plus se connecter.

=====Crackage clé WPA=====

On effectue la même démarche que pour le crackage de la clé WEP pour :
<pre>
airodump-ng --encrypt wpa wlan1
</pre>
On choisit de cracker cracotte03
<pre>
airodump-ng -w out --encrypt wpa -c 13 --bssid 04:DA:D2:9C:50:52 wlan1
</pre>
On obtient le handshake 04:DA:D2:9C:50:52

On crée le dictionnaire grâce à la commande :
<pre>
crunch 8 8 0123456789 > dico.txt
</pre>
On lance ensuite :
<pre>
airodump-ng --essid cracotte03 -c 13 --bssid 04:DA:D2:9C:50:52 -w dump wlan1
</pre>
On décode ensuite le fichier dump grâce à la commande :
<pre>
aircrack-ng dump-01.cap -w dico.txt -l KEY
</pre>
Après un long moment on obtient le résultat, la clé WPA est
<pre>
12399903
</pre>

=====Test configuration routeur=====
Pour tester la configuration de notre routeur, il fallait le relier au commutateur qui devait être relié au serveur cordouan.
Or pour cela, il nous était impossible de le relier en filaire. Nous avons donc utilisé la fibre.
Nous avons donc dû utiliser un convertisseur de l'interface 10Gi en deux interfaces Gi.
Une fois cela effectué, nous pouvions relier la fibre au commutateur qui était lui-même relié au serveur Cordouan.
Il fallait seulement changer le mode access du port sur le commutateur et le configurer en Trunk.

Une fois cela effectué et bien configuré, nous parvenons à "pinger" notre routeur depuis notre machine virtuelle.

<pre>
# ping 193.48.57.172
PING 193.48.57.172 (193.48.57.172) 56(84) bytes of data.
64 bytes from 193.48.57.172: icmp_seq=1 ttl=255 time=6.23 ms
64 bytes from 193.48.57.172: icmp_seq=2 ttl=255 time=1.01 ms
64 bytes from 193.48.57.172: icmp_seq=3 ttl=255 time=19.8 ms
64 bytes from 193.48.57.172: icmp_seq=4 ttl=255 time=1.56 ms
64 bytes from 193.48.57.172: icmp_seq=5 ttl=255 time=8.55 ms
64 bytes from 193.48.57.172: icmp_seq=6 ttl=255 time=2.36 ms
^C
--- 193.48.57.172 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 1.018/6.593/19.818/6.495 ms
</pre>

===Réalisation 5ème semaine ===

=====Configuration machine virtuelle=====
Installation des packages ssh, apache2 et bind9.

Modification du fichier :
<pre>
/etc/bind/db.hamtaro.space
</pre>

<pre>
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hamtaro.space. root.hamtaro.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN NS ns.hamtaro.space.
IN NS ns6.gandi.net.
IN MX 100 ns.hamtaro.space.

ns IN A 193.48.57.166
www IN A 193.48.57.166

</pre>

Modification du fichier :
<pre>
/etc/bind/named.conf.local
</pre>

<pre>
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "hamtaro.space" IN {
type master;
file "/etc/bind/db.hamtaro.space";
allow-transfer {217.70.177.40;};
};
</pre>

On va ensuite sur le site de Gandi pour modifier des informations.
Les Glue Records :
<pre>
'Nom du serveur' : ns.hamtaro.space
'IP' : 193.48.57.166
</pre>

Puis dans la rubrique modifier les serveurs DNS :
<pre>
'DNS1' : ns.hamtaro.space
'DNS2' : ns6.gandi.net
</pre>

Sécurisation de site web par certificat :

On tape la commande :
<pre>
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hamtaro.space.key -out hamtaro.space.csr
</pre>

Puis on remplis les champs demandés :
<pre>
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:hamtaro.space
</pre>

On se rend ensuite sur le site de Gandi et on rentre le contenu du fichier hamtaro.space.csr dans le champs CSR prévu à cet effet puis nous attendons la validation de notre certificat.

===== Configuration routeur=====
Configuration IPV6 des Vlan:
<pre>
ipv6 enable
ipv6 address 2001:660:4401:60XX::/64 eui-64
ipv6 nd prefix 2001:660:4401:60XX::/64 1000 900
</pre>

Avec les valeurs de XX variant de B0 à BA.
Pour le vlan130, cette valeur change : AA.

Interconnexion IPV4:
<pre>
router ospf 1
router-id 10.60.2.2
summary-address 10.60.0.0 255.255.0.0
summary-address 193.48.57.160 255.255.255.240
redistribute connected metric 30 subnets
network 192.168.222.0 0.0.0.7 area 1
</pre>

Interconnexion IPV6:
<pre>
ipv6 router rip tpima5sc
redistribute connected metric 1
redistribute static metric 1
redistribute rip 1 metric 1
</pre>

Une fois cela effectué, il faut que le vlan d'interconnexion prenne en compte ces modifications, il faut donc ajouter la commande :
<pre>
ipv6 rip tpima5sc enable
</pre>
Enfin, pour confirmer la configuration effectuée, nous affichons la table de routage ipv6 :
sh ipv6 route

On obtient alors le résultat suivant :
<pre>
IPv6 Routing Table - Default - 65 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, D - EIGRP, EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R ::/0 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:60::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6000::/56 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6002::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6003::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6004::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6005::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6006::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6007::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6008::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6009::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6011::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6013::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6014::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6015::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6016::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
...
</pre>

On essaie ensuite de ping le site de google depuis la machine virtuelle. On obtient un résultat positif. Notre configuration est donc fonctionnelle.

===== Sécurisation du réseau par HSRP =====
Pour empêcher les pertes de transmission de paquets, il faut ajouter une passerelle sur chaque interface.
De plus il faut ajouter l'adresse du routeur virtuel sur le vlan des machines virtuelles à savoir : 193.48.57.173.
On a alors :
<pre>
interface Vlan12
ip address 193.48.57.172 255.255.255.240
standby 1 ip 193.48.57.173
standby 1 priority 110
standby 1 preempt
</pre>

Une fois cela effectué sur notre routeur mais aussi sur le routeur de Stéphane et Thomas (groupe 5), nous réussissons à pinger leurs interfaces virtuelles ainsi que les interfaces de la machine virtuelle.
Nous pouvons également voir lors de l'affichage de la configuration en standby que notre routeur est considéré comme local tandis que le leur est en standby. La ligne traitant de la priorité fonctionne donc et permet la redondance du système.

===Réalisation 6ème semaine ===
====Suite Sécurisation SSL====
Après avoir obtenu notre certificat SSL sur le site GANDI, nous pouvons copier les fichiers utiles dans le dossier ssl:
<pre>
root@Flash:/etc/bind# cp certificat.crt /etc/ssl/certs/hamtaro.space.crt
root@Flash:/etc/bind# cp hamtaro.space.key /etc/ssl/private/hamtaro.space.key
root@Flash:/etc/bind# cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem
</pre>

Nous créons le fichier 000-hamtaro.space-ssl.conf dans le dossier "apache2/sites-available" afin de pouvoir joindre notre nom de serveur et Apache:
<pre>
#NameVirtualHost *:443
<VirtualHost 193.48.57.166:443>
ServerName www.hamtaro.space
ServerAlias hamtaro.space
DocumentRoot /var/www/www.hamtaro.space/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/hamtaro.space.crt
SSLCertificateKeyFile /etc/ssl/private/hamtaro.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem
SSLVerifyClient None
</VirtualHost>
<Directory /var/www/www.hamtaro.space>
Require all granted
</Directory>
ServerName "hamtaro.space"
</pre>

Enfin, nous devons modifier le fichier ports.conf afin que le serveur Apache écoute sur le port 443.
<pre>
Listen 80 443

<IfModule ssl_module>
Listen 443
</IfModule>

#<IfModule mod_gnutls.c>
# Listen 443
#</IfModule>

#<IfModule mod_ssl.c>
# Listen 443
#NameVirtualHost *:443
#</IfModule>
</pre>

Nous pouvons désormais activer le module SSL de apache :
<pre>a2enmod ssl</pre>

Puis nous pouvons activer notre certificat pour notre site :
<pre>
a2ensite 000-hamtaro.space-ssl.conf
Enabling site 000-hamtaro.space-ssl.
service apache2 reload //afin de charger la nouvelle configuration.
</pre>

Nous pouvons donc maintenant voir que notre site est sécurisé en allant sur https://www.hamtaro.space 
Il y a en effet le cadenas vert symbolisant cela:

[[Fichier:Screensecuresite.png]]

====Sécurisation par DNSSEC====

Dans un premier temps on va modifier le fichier /etc/bind/named.conf.options et rajouter la ligne :
<pre>
dnssec-enable yes
</pre>

Nous devons maintenant générer les clés (fichiers KSK et ZSK) que nous utiliserons afin de signer les zones:
<pre>
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hamtaro.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hamtaro.space
</pre>

Nous les plaçons dans un dossier nommé hamtaro.space.dnssec.

Nous modifions ensuite le fichier db.hamtaro.space afin d'inclure ces deux clés:
<pre>
$include /etc/bind/hamtaro.space.dnssec/hamtaro.space-ksk.key
$include /etc/bind/hamtaro.space.dnssec/hamtaro.space-zsk.key
</pre>

Il nous faut maintenant signer la zone :
<pre> dnssec-signzone -o hamtaro.space -k hamtaro.space-ksk ../db.hamtaro.space hamtaro.space-zsk
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.hamtaro.space.signed
</pre>

Nous ajoutons ensuite le DNSSEC sur Gandi :
[[Fichier:dnssecKadoc.png]]

On peut ensuite vérifier que notre DNSSEC est bien sécurisé :
<pre>
root@Kadoc:/etc/bind# dig DNSKEY hamtaro.space @localhost

; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> DNSKEY hamtaro.space @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5615
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;hamtaro.space. IN DNSKEY

;; AUTHORITY SECTION:
hamtaro.space. 604800 IN SOA ns.hamtaro.space. root.hamtaro.space.hamtaro.space. 3 604800 86400 2419200 604800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 28 13:21:10 CET 2016
;; MSG SIZE rcvd: 100

</pre>

====Partition RAID5====
Pour assurer la sécurisation des données, nous configurons trois partitions de volumes logiques sur la machine virtuelle:

<pre>
lvcreate -L 1G -n /dev/virtual/ima5-lapoulette
lvcreate -L 1G -n /dev/virtual/ima5-Karadoc
lvcreate -L 1G -n /dev/virtual/ima5-pelinord
</pre>

Puis nous modifions le fichier de configuration de notre machine virtuelle :
<pre>
disk = [
'file:/usr/local/xen/domains/Kadoc/disk.img,xvda2,w',
'file:/usr/local/xen/domains/Kadoc/swap.img,xvda1,w',
'phy:/dev/virtual/ima5-pelinord,xvdb,w',
'phy:/dev/virtual/ima5-Karadoc,xvdc,w',
'phy:/dev/virtual/ima5-lapoulette,xvdd,w',
]
</pre>

Nous pouvons maintenant relancer notre machine virtuelle.
Nous pouvons y créer le RAID5 avec les 3 partitions:
<pre> mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdb /dev/xvdc /dev/xvdd </pre>

On peut ensuite voir le détail de la configuration :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 12:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Nov 29 13:18:04 2016
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : 90156134:39a740fa:0de8c29d:486dce2c
Events : 22

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
1 202 32 1 active sync /dev/xvdc
3 202 48 2 active sync /dev/xvdd
</pre>

Nous devons ensuite sauvegarder cette configuration afin de garder notre md0, pour cela:
<pre> mdadm --detail --scan >> /etc/mdadm/mdadm.conf </pre>
puis nous pouvons copier les données sur le RAID5:
<pre>
root@Kadoc:~# mkfs /dev/md0
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 523776 4k blocks and 131072 inodes
Filesystem UUID: 2703e116-ed2c-46fe-964a-928be0b34cd6
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
</pre>
Puis:
<pre>
root@Kadoc:~# mount /dev/md0 /mnt
[ 702.230079] EXT4-fs (md0): mounting ext2 file system using the ext4 subsystem
[ 702.309734] EXT4-fs (md0): mounted filesystem without journal. Opts: (null)
</pre>

Nous allons maintenant voir ce qu'il se passe lorsque l'on enlève une des partitions à la machine.
Nous redémarrons la machine virtuelle et nous affichons le détail :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 12:23:50 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Tue Nov 29 12:43:56 2016
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : b333670e:27b24fbe:045a7e98:c7eafb49
Events : 14

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
2 0 0 2 removed
2 202 48 2 active sync /dev/xvdd
</pre>

Nous voyons donc bien qu'une partition a été enlevée.
Pour réparer cela,
<pre>
mdadm --set-faulty /dev/md0 /dev/xvdc
mdadm --remove /dev/md0 /dev/xvdc
</pre>

La partition est bien supprimée:
<pre>
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdb[0] xvdd[3]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
</pre>

On remet la partition:
<pre>mdadm --add /dev/md0 /dev/xvdc</pre>

On peut ensuite suivre l'avancement de la restauration:
<pre>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===========>.........] recovery = 56.9% (596964/1047552) finish=0.2min speed=29848K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=============>.......] recovery = 66.9% (701992/1047552) finish=0.1min speed=29249K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===============>.....] recovery = 75.0% (786728/1047552) finish=0.1min speed=29138K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=================>...] recovery = 85.1% (892660/1047552) finish=0.0min speed=29755K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 99.6% (1044732/1047552) finish=0.0min speed=30465K/sec

unused devices: <none>
root@Kadoc:/dev# [ 156.292138] md: md0: recovery done.
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>
</pre>

Enfin, on retrouve la configuration initiale :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Nov 29 13:18:04 2016
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : 90156134:39a740fa:0de8c29d:486dce2c
Events : 22

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
1 202 32 1 active sync /dev/xvdc
3 202 48 2 active sync /dev/xvdd
</pre>

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

Pour cette partie, nous commençons par installer lvm2, Gparted ainsi que cryptsetup sur notre eeePc.
Nous voulons une seule partition sur la carte SD. Pour cela on utilise:
<pre>
fdisk /dev/mmcblk1
</pre>
On créé alors une partition primaire sur tout l'espace disponible de la carte.

Une fois cette partition créée, elle n'est pas cryptée, nous allons donc maintenant utiliser le cryptsetup:

<pre>
cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
</pre>
Cette commande permet de formatter la partition au type Luks avec un chiffrement AES avec un algorithme de hâchage SHA256.
On doit aussi choisir un mot de passe pour crypter la partition.

Pour voir l'état du conteneur, on peut utiliser la commande :
<pre>
root@lamproie:~# cryptsetup luksDump /dev/mmcblk1
LUKS header information for /dev/mmcblk1

Version: 1
Cipher name: aes
Cipher mode: cbc-plain
Hash spec: sha256
Payload offset: 4096
MK bits: 256
MK digest: b9 ed bc f9 68 3c ac 64 d4 3b a4 44 5b 48 38 b2 d1 b4 7d 87
MK salt: 8a a5 f6 38 a7 08 fe 6b 90 7d 88 79 10 fc 70 15
95 e0 67 82 ee 34 fe 87 23 3e 2a 77 f7 ed cf 35
MK iterations: 125750
UUID: 07082d69-6117-42f8-81a3-695d1ea8e5df

Key Slot 0: ENABLED
Iterations: 1007873
Salt: 98 b5 bd 00 ca 5b 70 81 62 50 8d 5f ba ea d9 4c
35 38 70 bf 09 0b da 95 51 cb 81 c0 35 2d fe da
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
</pre>

On ouvre ensuite notre partition cryptée:
<pre> cryptsetup luksOpen /dev/mmcblk1 kadoc </pre>

On peut ainsi ajouter le système de fichiers à notre partition cryptée:
<pre>mkfs.ext3 /dev/mapper/kadoc</pre>

Ensuite, nous pouvons monter la partition pour pouvoir y écrire. Nous pouvons aussi la démonter lorsque nos fichiers seront copiés:
<pre>
mount -t ext3 /dev/mapper/kadoc /mnt/ //pour monter la partition.

umount /mnt/ //pour démonter la partition.
</pre>

Enfin pour encrypter à nouveau cette partition, on utilise la commande:
<pre> cryptsetup luksClose kadoc </pre>

On utilise la commande <pre> gparted /dev/mmcblk1 </pre> afin de voir la partition, on obtient ceci:

[[Fichier:Screencrypt.png]]

On voit donc que les informations de cette partition ne sont pas disponibles à moins d'avoir la clé.

===Réalisation 7ème semaine ===
Lors de cette semaine nous avons pu connecter le points d'accès Wifi de Valentin et Alexandre sur le commutateur de la salle E304. Pour cela, nous avons dû configurer un vlan1 sur le routeur qui prend l'adresse 10.60.1.3.
Ainsi, nous avons pu nous trouver ce point d'accès qui a pris l'adresse 10.60.1.6.
Nous avions ainsi les deux points d'accès qui étaient connectés dans chaque salle :
En E304 : avec l'adresse 10.60.1.6 et en E306 : 10.60.1.2.

Une fois cela fait, nous pouvons passer à la sécurisation Wifi par WPA2-EAP.

=====Sécurisation Wifi par WPA2-EAP=====
Nous allons utiliser cette méthode afin de créer le point d'accès que nous avons mentionné plus haut et d'en sécuriser la connexion.
Tout d'abord, nous devons créer le serveur FreeRadius:
Nous devons tout d'abord modifier certains fichiers de configuration du serveur :
dans le fichier ''eap.conf'' nous devons modifier une ligne afin de modifier le protocole d'identification :
<pre> default_eap_type = peap </pre>

Une fois cela fait, nous devons modifier le fichier ''clients.conf'', ce qui nous permettra de configurer nos points d'accès Wifi:
<pre>

client E304 {
ipaddr = 10.60.1.6
secret = kadoc
shortname = wifi1
}

client E306 {
ipaddr = 10.60.1.2
secret = kadoc
shortname = wifi2
}
</pre>
Nous avons ainsi configuré les deux points d'accès.

Enfin, nous devons ajouter une ligne au fichier users qui va nous permettre de créer un nouvel utilisateur pour l'identification:
<pre> karadoc Cleartext-Password := "perceval" </pre>

Une fois cela fait, nous pouvons lancer notre serveur FreeRadius.

Nous allons maintenant passer à la configuration du point d'accès afin d'avoir un accès sécurisé avec notre serveur précédemment détaillé:
<pre>
telnet 10.60.1.6

...

conf t

aaa new-model
aaa authentication login eap_kadoc group radius_kadoc
radius-server host 193.48.57.166 auth-port 1812 acct-port 1813 key kadoc
aaa group server radius radius_kadoc
server 193.48.57.166 auth-port 1812 acct-port 1813

exit

dot11 ssid SSID_KADOC
vlan 7
authentication open eap eap_kadoc
authentication network-eap eap_kadoc
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 7 mode ciphers aes-ccm tkip
ssid SSID_KADOC

exit

interface Dot11Radio0.7
encapsulation dot1Q 7
no ip route-cache
bridge-group 7
bridge-group 7 subscriber-loop-control
bridge-group 7 spanning-disabled
bridge-group 7 block-unknown-source
no bridge-group 7 source-learning
no bridge-group 7 unicast-flooding

exit

interface GigabitEthernet0.7
encapsulation dot1Q 7
bridge-group 7

exit

exit

write
</pre>

La borne est maintenant configurée, il ne nous reste plus qu'à nous y connecter.

Pour cela, nous devons encore modifier le wlan0 de l'eeepc.
Nous modifions donc le fichier /etc/network/interfaces :
<pre>
auto wlan0
iface wlan0 inet static
address 10.60.7.7
netmask 255.255.255.0
gateway 10.60.7.1
wpa-ssid KADOC
wpa-key-mgmt WPA-EAP
wpa-identity karadoc
wpa-password perceval
</pre>

Une fois cela fait, nous pouvons nous connecter sur le point d'accès de la salle E304. Pour se connecter sur celui de la E306, il faudrait faire la même configuration sur ce point d'accès.
Nous avons réussi à nous connecter à ce point d'accès en rentrant une adresse IP valide à la main. Pour rendre cela automatique, nous devrons installer un serveur DHCP sur notre Eeepc qui nous permettre d'attribuer une adresse IP à notre smartphone
Une fois notre serveur DHCP installé et correctement configuré, nous pouvons nous connecter comme prévu sans avoir à rentrer une adresse IP "à la main".

[[Fichier:KadocConnected.png||200px||center]]

===Réalisation 9ème semaine ===

Nous avons dans un premier temps installer Asterisk
<pre>
apt-get install asterisk
</pre>

Nous avons ensuite configuré le fichier <pre> /etc/asterisk/users.conf </pre> en y ajoutant :
<pre>
[general]
hasvoicemail = yes
hassip = yes
hasiax = yes
callwaiting = yes
threewaycalling = yes
callwaitingcallerid = yes
transfer = yes
canpark = yes
cancallforward = yes
callreturn = yes
callgroup = 1
pickupgroup = 1
nat = yes

[6001]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = kadoc
username = heykadoc
secret = perceval
context = work

[6002]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = karadoc
username = heykaradoc
secret = perceval
context = work
</pre>

Ensuite, on ajoute dans le fichier <pre>/etc/asterisk/extensions.conf :</pre>
<pre>
[work]
exten => _6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()
</pre>

On restart ensuite asterisk :
<pre>
service asterisk restart
</pre>

Puis on reload l'ensemble des fichiers afin qu'ils soient pris en compte :
<pre>
reload
</pre>

On cherche maintenant à savoir si notre configuration fonctionne. Pour cela, nous installons l'application CSipSimple sur deux téléphones Android sur lesquels nous configurons deux comptes.

Lorsque nous essayons de nous appeler, nous voyons que la communication fonctionne:
[[Fichier:15497641_10210148661905836_1314328693_n.jpg||400px||center]]

Cahier 2016 groupe n°6

2017-01-03T14:00:02Z

Rlentieu : /* Sécurisation Wifi par WPA2-EAP */

Fichier:KadocConnected.png

2017-01-03T13:58:52Z

Rlentieu :

Cahier 2016 groupe n°6

2017-01-03T13:57:33Z

Rlentieu : /* Sécurisation Wifi par WPA2-EAP */

== Cahier des charges ==
=== Présentation du travail ===

==== Répartition du travail ====

{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/10)
| Connaissances du TP/ Recherche sur le routeur 3560E / Installation de la machine virtuelle
|-
! scope="row" | Séance 2 (10/10)
| Création des VLAN
|-
! scope="row" | Séance 3 (13/10)
| Création des VLAN / Création de la machine virtuelle
|-
! scope="row" | Séance 4 (24/10)
| Crackage de clé WEP
|-
! scope="row" | Séance 5 (07/11)
| Configuration Eeepc / Crackage clé WPA / Test de la configuration locale
|-
! scope="row" | Séance 6 (14/11)
| Configuration machine virtuelle / Configuration routeur ipv6 / interconnexion ipv4 et ipv6 / HSRP
|-
! scope="row" | Séance 7 (28/11)
| Configuration machine Virtuelle SSL / DNSSEC / Partition RAID5 / Cryptage des données
|-
! scope="row" | Séance 8 (05/12)
| Configuration Routeur pour Point d'Accès WIFI / Sécurisation Wifi par WPA2-EAP
|-
! scope="row" | Séance 9 (12/12)
| Configuration Asterisk et test de la VoIP
|}

===Réalisation 1ère semaine ===

Pour la première séance nous nous sommes chargés d'installer la machine virtuelle Xen à l'aide de la commande :
<pre>
xen-create-image --hostname=Kadoc --ip=193.48.57.166 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --gateway=193.48.57.172
--netmask=255.255.255.240 --dir=/usr/local/xen --passwd
</pre>
Ainsi, nous obtenons ce résultat:
<pre>
Installation Summary
---------------------
Hostname : Kadoc
Distribution : jessie
MAC Address : 00:16:3E:60:01:B1
IP Address(es) : 193.48.57.166
RSA Fingerprint : cf:03:35:4e:b7:f1:d4:f5:52:a1:d7:52:63:5d:83:57
Root Password : N/A
</pre>

===Réalisation 2ème semaine ===
=====VLANs=====
Durant les deux séances de cette semaine, nous avons réalisé la configuration locale du routeur 3560E, notamment la configuration des VLANs.

Pour cela, nous avons utilisé la communication série.
Lors du démarrage, nous devons le configurer :
<pre>
conf t
hostname Perceval
enable secret pasglop
</pre>

Nous passons maintenant à la configuration des VLANs:

Nous avons 11 VLANs à configurer :
* VLAN2 à VLAN11 : un pour chaque groupe
* VLAN12 : pour les machines virtuelles et donc le lien entre Cordouan et les commutateurs
* VLAN13 : pour l'interconnexion, c'est à dire le lien entre notre routeur et le routeur de l'école.

Pour la configuration, nous prendrons l'exemple du vlan 2.
Tout d'abord, nous affectons aux VLANs utiles:
<pre>
vlan 2
name Vlan2
exit
</pre>

Une fois le nom affecté :
<pre>
conf t
int Vlan2
ip address 10.60.2.2 255.255.255.0
exit
</pre>

=====Machine virtuelle=====

Tout d'abord, nous nous connectons sur le serveur cordouan:
<pre>
ssh root@cordouan.insecserv.deule.net
</pre>

Nous créons ensuite la machine avec tous les renseignements souhaités
<pre>
xen-create-image --hostname=Kadoc --ip=193.48.57.166 --netmask=255.255.255.240 --gateway=193.48.57.172
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie
</pre>
Enfin on démarre la machine virtuelle
<pre>
xl create /etc/xen/Kadoc.cfg
</pre>
Puis nous la lançons
<pre>
xl console Kadoc
</pre>

Lors de cette séance, nous avons aussi réservé notre nom de domaine sur Gandi : hamtaro.space

Nous avons également modifier le fichier de configuration de la VM en modifiant le fichier "/etc/xen/Kadoc.cfg" pour la taille mémoire 'de 128 à 512MB" ainsi que pour ajouter le bridge IMA5sc.

===Réalisation 3ème semaine ===
=====crackage clé WEP=====
1ere commande : airodump-ng --encrypt wep wlan2
BSSID PWR Beacons #data #/s CH MB ENC CIPHER AUTH ESSID
04:DA:D2:9C:50:56 -57 1 65 32 2 54e. WEP WEP cracotte07

La cible que nous avons choisie est "cracotte07", donc on utilise la commande suivante :

airodump-ng --essid cracotte07 --channel 2 -w testcrack wlan2

On obtient:

CH 2 ][ Elapsed: 3 mins ][ 2014-12-12 18:15
<pre>
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
04:DA:D2:9C:50:56 -55 6 505 9516 231 2 54e. WEP WEP cracotte07
</pre>
Le monitoring est donc lancé, nous pouvons passer au crackage :
aircrack-ng testcrack-01.cap

On obtient finalement la clé :

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:E4:44:44:44 ]
Decrypted correctly: 100%

===Réalisation 4ème semaine===

=====Configuration eeePC =====
''SSH:''

On modifie le fichier /etc/resolv.conf
<pre>
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
</pre>

Pour pouvoir se connecter en ssh il est nécessaire de modifier le ficher /etc/network/interfaces de la façon suivante :
rajouter les lignes :
<pre>
auto wlan2
iface wlan2 inet static
wireless mode-managed
wireless essid Wolverine // pour se connecter à la borne Wifi
wireless-key 0123456789 // mot de passe de la borne
address 172.26.79.22 // notre adresse
netmask 255.255.255.240
gateway 172.26.79.254
</pre>

''Intrusion par changement d'adresse MAC''
En changeant notre adresse MAC grâce à la commande
<pre>
ifconfig wlan2 down
ifconfig wlan2 hw ether 74:29:af:f3:fd:71
ifconfig wlan2 up
</pre>
On ne peut plus se connecter.

=====Crackage clé WPA=====

On effectue la même démarche que pour le crackage de la clé WEP pour :
<pre>
airodump-ng --encrypt wpa wlan1
</pre>
On choisit de cracker cracotte03
<pre>
airodump-ng -w out --encrypt wpa -c 13 --bssid 04:DA:D2:9C:50:52 wlan1
</pre>
On obtient le handshake 04:DA:D2:9C:50:52

On crée le dictionnaire grâce à la commande :
<pre>
crunch 8 8 0123456789 > dico.txt
</pre>
On lance ensuite :
<pre>
airodump-ng --essid cracotte03 -c 13 --bssid 04:DA:D2:9C:50:52 -w dump wlan1
</pre>
On décode ensuite le fichier dump grâce à la commande :
<pre>
aircrack-ng dump-01.cap -w dico.txt -l KEY
</pre>
Après un long moment on obtient le résultat, la clé WPA est
<pre>
12399903
</pre>

=====Test configuration routeur=====
Pour tester la configuration de notre routeur, il fallait le relier au commutateur qui devait être relié au serveur cordouan.
Or pour cela, il nous était impossible de le relier en filaire. Nous avons donc utilisé la fibre.
Nous avons donc dû utiliser un convertisseur de l'interface 10Gi en deux interfaces Gi.
Une fois cela effectué, nous pouvions relier la fibre au commutateur qui était lui-même relié au serveur Cordouan.
Il fallait seulement changer le mode access du port sur le commutateur et le configurer en Trunk.

Une fois cela effectué et bien configuré, nous parvenons à "pinger" notre routeur depuis notre machine virtuelle.

<pre>
# ping 193.48.57.172
PING 193.48.57.172 (193.48.57.172) 56(84) bytes of data.
64 bytes from 193.48.57.172: icmp_seq=1 ttl=255 time=6.23 ms
64 bytes from 193.48.57.172: icmp_seq=2 ttl=255 time=1.01 ms
64 bytes from 193.48.57.172: icmp_seq=3 ttl=255 time=19.8 ms
64 bytes from 193.48.57.172: icmp_seq=4 ttl=255 time=1.56 ms
64 bytes from 193.48.57.172: icmp_seq=5 ttl=255 time=8.55 ms
64 bytes from 193.48.57.172: icmp_seq=6 ttl=255 time=2.36 ms
^C
--- 193.48.57.172 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 1.018/6.593/19.818/6.495 ms
</pre>

===Réalisation 5ème semaine ===

=====Configuration machine virtuelle=====
Installation des packages ssh, apache2 et bind9.

Modification du fichier :
<pre>
/etc/bind/db.hamtaro.space
</pre>

<pre>
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hamtaro.space. root.hamtaro.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN NS ns.hamtaro.space.
IN NS ns6.gandi.net.
IN MX 100 ns.hamtaro.space.

ns IN A 193.48.57.166
www IN A 193.48.57.166

</pre>

Modification du fichier :
<pre>
/etc/bind/named.conf.local
</pre>

<pre>
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "hamtaro.space" IN {
type master;
file "/etc/bind/db.hamtaro.space";
allow-transfer {217.70.177.40;};
};
</pre>

On va ensuite sur le site de Gandi pour modifier des informations.
Les Glue Records :
<pre>
'Nom du serveur' : ns.hamtaro.space
'IP' : 193.48.57.166
</pre>

Puis dans la rubrique modifier les serveurs DNS :
<pre>
'DNS1' : ns.hamtaro.space
'DNS2' : ns6.gandi.net
</pre>

Sécurisation de site web par certificat :

On tape la commande :
<pre>
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hamtaro.space.key -out hamtaro.space.csr
</pre>

Puis on remplis les champs demandés :
<pre>
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:hamtaro.space
</pre>

On se rend ensuite sur le site de Gandi et on rentre le contenu du fichier hamtaro.space.csr dans le champs CSR prévu à cet effet puis nous attendons la validation de notre certificat.

===== Configuration routeur=====
Configuration IPV6 des Vlan:
<pre>
ipv6 enable
ipv6 address 2001:660:4401:60XX::/64 eui-64
ipv6 nd prefix 2001:660:4401:60XX::/64 1000 900
</pre>

Avec les valeurs de XX variant de B0 à BA.
Pour le vlan130, cette valeur change : AA.

Interconnexion IPV4:
<pre>
router ospf 1
router-id 10.60.2.2
summary-address 10.60.0.0 255.255.0.0
summary-address 193.48.57.160 255.255.255.240
redistribute connected metric 30 subnets
network 192.168.222.0 0.0.0.7 area 1
</pre>

Interconnexion IPV6:
<pre>
ipv6 router rip tpima5sc
redistribute connected metric 1
redistribute static metric 1
redistribute rip 1 metric 1
</pre>

Une fois cela effectué, il faut que le vlan d'interconnexion prenne en compte ces modifications, il faut donc ajouter la commande :
<pre>
ipv6 rip tpima5sc enable
</pre>
Enfin, pour confirmer la configuration effectuée, nous affichons la table de routage ipv6 :
sh ipv6 route

On obtient alors le résultat suivant :
<pre>
IPv6 Routing Table - Default - 65 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, D - EIGRP, EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R ::/0 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:60::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6000::/56 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6002::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6003::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6004::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6005::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6006::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6007::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6008::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6009::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6011::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6013::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6014::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6015::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6016::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
...
</pre>

On essaie ensuite de ping le site de google depuis la machine virtuelle. On obtient un résultat positif. Notre configuration est donc fonctionnelle.

===== Sécurisation du réseau par HSRP =====
Pour empêcher les pertes de transmission de paquets, il faut ajouter une passerelle sur chaque interface.
De plus il faut ajouter l'adresse du routeur virtuel sur le vlan des machines virtuelles à savoir : 193.48.57.173.
On a alors :
<pre>
interface Vlan12
ip address 193.48.57.172 255.255.255.240
standby 1 ip 193.48.57.173
standby 1 priority 110
standby 1 preempt
</pre>

Une fois cela effectué sur notre routeur mais aussi sur le routeur de Stéphane et Thomas (groupe 5), nous réussissons à pinger leurs interfaces virtuelles ainsi que les interfaces de la machine virtuelle.
Nous pouvons également voir lors de l'affichage de la configuration en standby que notre routeur est considéré comme local tandis que le leur est en standby. La ligne traitant de la priorité fonctionne donc et permet la redondance du système.

===Réalisation 6ème semaine ===
====Suite Sécurisation SSL====
Après avoir obtenu notre certificat SSL sur le site GANDI, nous pouvons copier les fichiers utiles dans le dossier ssl:
<pre>
root@Flash:/etc/bind# cp certificat.crt /etc/ssl/certs/hamtaro.space.crt
root@Flash:/etc/bind# cp hamtaro.space.key /etc/ssl/private/hamtaro.space.key
root@Flash:/etc/bind# cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem
</pre>

Nous créons le fichier 000-hamtaro.space-ssl.conf dans le dossier "apache2/sites-available" afin de pouvoir joindre notre nom de serveur et Apache:
<pre>
#NameVirtualHost *:443
<VirtualHost 193.48.57.166:443>
ServerName www.hamtaro.space
ServerAlias hamtaro.space
DocumentRoot /var/www/www.hamtaro.space/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/hamtaro.space.crt
SSLCertificateKeyFile /etc/ssl/private/hamtaro.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem
SSLVerifyClient None
</VirtualHost>
<Directory /var/www/www.hamtaro.space>
Require all granted
</Directory>
ServerName "hamtaro.space"
</pre>

Enfin, nous devons modifier le fichier ports.conf afin que le serveur Apache écoute sur le port 443.
<pre>
Listen 80 443

<IfModule ssl_module>
Listen 443
</IfModule>

#<IfModule mod_gnutls.c>
# Listen 443
#</IfModule>

#<IfModule mod_ssl.c>
# Listen 443
#NameVirtualHost *:443
#</IfModule>
</pre>

Nous pouvons désormais activer le module SSL de apache :
<pre>a2enmod ssl</pre>

Puis nous pouvons activer notre certificat pour notre site :
<pre>
a2ensite 000-hamtaro.space-ssl.conf
Enabling site 000-hamtaro.space-ssl.
service apache2 reload //afin de charger la nouvelle configuration.
</pre>

Nous pouvons donc maintenant voir que notre site est sécurisé en allant sur https://www.hamtaro.space 
Il y a en effet le cadenas vert symbolisant cela:

[[Fichier:Screensecuresite.png]]

====Sécurisation par DNSSEC====

Dans un premier temps on va modifier le fichier /etc/bind/named.conf.options et rajouter la ligne :
<pre>
dnssec-enable yes
</pre>

Nous devons maintenant générer les clés (fichiers KSK et ZSK) que nous utiliserons afin de signer les zones:
<pre>
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hamtaro.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hamtaro.space
</pre>

Nous les plaçons dans un dossier nommé hamtaro.space.dnssec.

Nous modifions ensuite le fichier db.hamtaro.space afin d'inclure ces deux clés:
<pre>
$include /etc/bind/hamtaro.space.dnssec/hamtaro.space-ksk.key
$include /etc/bind/hamtaro.space.dnssec/hamtaro.space-zsk.key
</pre>

Il nous faut maintenant signer la zone :
<pre> dnssec-signzone -o hamtaro.space -k hamtaro.space-ksk ../db.hamtaro.space hamtaro.space-zsk
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.hamtaro.space.signed
</pre>

Nous ajoutons ensuite le DNSSEC sur Gandi :
[[Fichier:dnssecKadoc.png]]

On peut ensuite vérifier que notre DNSSEC est bien sécurisé :
<pre>
root@Kadoc:/etc/bind# dig DNSKEY hamtaro.space @localhost

; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> DNSKEY hamtaro.space @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5615
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;hamtaro.space. IN DNSKEY

;; AUTHORITY SECTION:
hamtaro.space. 604800 IN SOA ns.hamtaro.space. root.hamtaro.space.hamtaro.space. 3 604800 86400 2419200 604800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 28 13:21:10 CET 2016
;; MSG SIZE rcvd: 100

</pre>

====Partition RAID5====
Pour assurer la sécurisation des données, nous configurons trois partitions de volumes logiques sur la machine virtuelle:

<pre>
lvcreate -L 1G -n /dev/virtual/ima5-lapoulette
lvcreate -L 1G -n /dev/virtual/ima5-Karadoc
lvcreate -L 1G -n /dev/virtual/ima5-pelinord
</pre>

Puis nous modifions le fichier de configuration de notre machine virtuelle :
<pre>
disk = [
'file:/usr/local/xen/domains/Kadoc/disk.img,xvda2,w',
'file:/usr/local/xen/domains/Kadoc/swap.img,xvda1,w',
'phy:/dev/virtual/ima5-pelinord,xvdb,w',
'phy:/dev/virtual/ima5-Karadoc,xvdc,w',
'phy:/dev/virtual/ima5-lapoulette,xvdd,w',
]
</pre>

Nous pouvons maintenant relancer notre machine virtuelle.
Nous pouvons y créer le RAID5 avec les 3 partitions:
<pre> mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdb /dev/xvdc /dev/xvdd </pre>

On peut ensuite voir le détail de la configuration :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 12:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Nov 29 13:18:04 2016
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : 90156134:39a740fa:0de8c29d:486dce2c
Events : 22

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
1 202 32 1 active sync /dev/xvdc
3 202 48 2 active sync /dev/xvdd
</pre>

Nous devons ensuite sauvegarder cette configuration afin de garder notre md0, pour cela:
<pre> mdadm --detail --scan >> /etc/mdadm/mdadm.conf </pre>
puis nous pouvons copier les données sur le RAID5:
<pre>
root@Kadoc:~# mkfs /dev/md0
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 523776 4k blocks and 131072 inodes
Filesystem UUID: 2703e116-ed2c-46fe-964a-928be0b34cd6
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
</pre>
Puis:
<pre>
root@Kadoc:~# mount /dev/md0 /mnt
[ 702.230079] EXT4-fs (md0): mounting ext2 file system using the ext4 subsystem
[ 702.309734] EXT4-fs (md0): mounted filesystem without journal. Opts: (null)
</pre>

Nous allons maintenant voir ce qu'il se passe lorsque l'on enlève une des partitions à la machine.
Nous redémarrons la machine virtuelle et nous affichons le détail :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 12:23:50 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Tue Nov 29 12:43:56 2016
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : b333670e:27b24fbe:045a7e98:c7eafb49
Events : 14

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
2 0 0 2 removed
2 202 48 2 active sync /dev/xvdd
</pre>

Nous voyons donc bien qu'une partition a été enlevée.
Pour réparer cela,
<pre>
mdadm --set-faulty /dev/md0 /dev/xvdc
mdadm --remove /dev/md0 /dev/xvdc
</pre>

La partition est bien supprimée:
<pre>
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdb[0] xvdd[3]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
</pre>

On remet la partition:
<pre>mdadm --add /dev/md0 /dev/xvdc</pre>

On peut ensuite suivre l'avancement de la restauration:
<pre>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===========>.........] recovery = 56.9% (596964/1047552) finish=0.2min speed=29848K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=============>.......] recovery = 66.9% (701992/1047552) finish=0.1min speed=29249K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===============>.....] recovery = 75.0% (786728/1047552) finish=0.1min speed=29138K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=================>...] recovery = 85.1% (892660/1047552) finish=0.0min speed=29755K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 99.6% (1044732/1047552) finish=0.0min speed=30465K/sec

unused devices: <none>
root@Kadoc:/dev# [ 156.292138] md: md0: recovery done.
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>
</pre>

Enfin, on retrouve la configuration initiale :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Nov 29 13:18:04 2016
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : 90156134:39a740fa:0de8c29d:486dce2c
Events : 22

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
1 202 32 1 active sync /dev/xvdc
3 202 48 2 active sync /dev/xvdd
</pre>

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

Pour cette partie, nous commençons par installer lvm2, Gparted ainsi que cryptsetup sur notre eeePc.
Nous voulons une seule partition sur la carte SD. Pour cela on utilise:
<pre>
fdisk /dev/mmcblk1
</pre>
On créé alors une partition primaire sur tout l'espace disponible de la carte.

Une fois cette partition créée, elle n'est pas cryptée, nous allons donc maintenant utiliser le cryptsetup:

<pre>
cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
</pre>
Cette commande permet de formatter la partition au type Luks avec un chiffrement AES avec un algorithme de hâchage SHA256.
On doit aussi choisir un mot de passe pour crypter la partition.

Pour voir l'état du conteneur, on peut utiliser la commande :
<pre>
root@lamproie:~# cryptsetup luksDump /dev/mmcblk1
LUKS header information for /dev/mmcblk1

Version: 1
Cipher name: aes
Cipher mode: cbc-plain
Hash spec: sha256
Payload offset: 4096
MK bits: 256
MK digest: b9 ed bc f9 68 3c ac 64 d4 3b a4 44 5b 48 38 b2 d1 b4 7d 87
MK salt: 8a a5 f6 38 a7 08 fe 6b 90 7d 88 79 10 fc 70 15
95 e0 67 82 ee 34 fe 87 23 3e 2a 77 f7 ed cf 35
MK iterations: 125750
UUID: 07082d69-6117-42f8-81a3-695d1ea8e5df

Key Slot 0: ENABLED
Iterations: 1007873
Salt: 98 b5 bd 00 ca 5b 70 81 62 50 8d 5f ba ea d9 4c
35 38 70 bf 09 0b da 95 51 cb 81 c0 35 2d fe da
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
</pre>

On ouvre ensuite notre partition cryptée:
<pre> cryptsetup luksOpen /dev/mmcblk1 kadoc </pre>

On peut ainsi ajouter le système de fichiers à notre partition cryptée:
<pre>mkfs.ext3 /dev/mapper/kadoc</pre>

Ensuite, nous pouvons monter la partition pour pouvoir y écrire. Nous pouvons aussi la démonter lorsque nos fichiers seront copiés:
<pre>
mount -t ext3 /dev/mapper/kadoc /mnt/ //pour monter la partition.

umount /mnt/ //pour démonter la partition.
</pre>

Enfin pour encrypter à nouveau cette partition, on utilise la commande:
<pre> cryptsetup luksClose kadoc </pre>

On utilise la commande <pre> gparted /dev/mmcblk1 </pre> afin de voir la partition, on obtient ceci:

[[Fichier:Screencrypt.png]]

On voit donc que les informations de cette partition ne sont pas disponibles à moins d'avoir la clé.

===Réalisation 7ème semaine ===
Lors de cette semaine nous avons pu connecter le points d'accès Wifi de Valentin et Alexandre sur le commutateur de la salle E304. Pour cela, nous avons dû configurer un vlan1 sur le routeur qui prend l'adresse 10.60.1.3.
Ainsi, nous avons pu nous trouver ce point d'accès qui a pris l'adresse 10.60.1.6.
Nous avions ainsi les deux points d'accès qui étaient connectés dans chaque salle :
En E304 : avec l'adresse 10.60.1.6 et en E306 : 10.60.1.2.

Une fois cela fait, nous pouvons passer à la sécurisation Wifi par WPA2-EAP.

=====Sécurisation Wifi par WPA2-EAP=====
Nous allons utiliser cette méthode afin de créer le point d'accès que nous avons mentionné plus haut et d'en sécuriser la connexion.
Tout d'abord, nous devons créer le serveur FreeRadius:
Nous devons tout d'abord modifier certains fichiers de configuration du serveur :
dans le fichier ''eap.conf'' nous devons modifier une ligne afin de modifier le protocole d'identification :
<pre> default_eap_type = peap </pre>

Une fois cela fait, nous devons modifier le fichier ''clients.conf'', ce qui nous permettra de configurer nos points d'accès Wifi:
<pre>

client E304 {
ipaddr = 10.60.1.6
secret = kadoc
shortname = wifi1
}

client E306 {
ipaddr = 10.60.1.2
secret = kadoc
shortname = wifi2
}
</pre>
Nous avons ainsi configuré les deux points d'accès.

Enfin, nous devons ajouter une ligne au fichier users qui va nous permettre de créer un nouvel utilisateur pour l'identification:
<pre> karadoc Cleartext-Password := "perceval" </pre>

Une fois cela fait, nous pouvons lancer notre serveur FreeRadius.

Nous allons maintenant passer à la configuration du point d'accès afin d'avoir un accès sécurisé avec notre serveur précédemment détaillé:
<pre>
telnet 10.60.1.6

...

conf t

aaa new-model
aaa authentication login eap_kadoc group radius_kadoc
radius-server host 193.48.57.166 auth-port 1812 acct-port 1813 key kadoc
aaa group server radius radius_kadoc
server 193.48.57.166 auth-port 1812 acct-port 1813

exit

dot11 ssid SSID_KADOC
vlan 7
authentication open eap eap_kadoc
authentication network-eap eap_kadoc
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 7 mode ciphers aes-ccm tkip
ssid SSID_KADOC

exit

interface Dot11Radio0.7
encapsulation dot1Q 7
no ip route-cache
bridge-group 7
bridge-group 7 subscriber-loop-control
bridge-group 7 spanning-disabled
bridge-group 7 block-unknown-source
no bridge-group 7 source-learning
no bridge-group 7 unicast-flooding

exit

interface GigabitEthernet0.7
encapsulation dot1Q 7
bridge-group 7

exit

exit

write
</pre>

La borne est maintenant configurée, il ne nous reste plus qu'à nous y connecter.

Pour cela, nous devons encore modifier le wlan0 de l'eeepc.
Nous modifions donc le fichier /etc/network/interfaces :
<pre>
auto wlan0
iface wlan0 inet static
address 10.60.7.7
netmask 255.255.255.0
gateway 10.60.7.1
wpa-ssid KADOC
wpa-key-mgmt WPA-EAP
wpa-identity karadoc
wpa-password perceval
</pre>

Une fois cela fait, nous pouvons nous connecter sur le point d'accès de la salle E304. Pour se connecter sur celui de la E306, il faudrait faire la même configuration sur ce point d'accès.
Nous avons réussi à nous connecter à ce point d'accès en rentrant une adresse IP valide à la main. Pour rendre cela automatique, nous devrons installer un serveur DHCP sur notre Eeepc qui nous permettre d'attribuer une adresse IP à notre smartphone
Une fois notre serveur DHCP installé et correctement configuré, nous pouvons nous connecter comme prévu sans avoir à rentrer une adresse IP "à la main".

===Réalisation 9ème semaine ===

Nous avons dans un premier temps installer Asterisk
<pre>
apt-get install asterisk
</pre>

Nous avons ensuite configuré le fichier <pre> /etc/asterisk/users.conf </pre> en y ajoutant :
<pre>
[general]
hasvoicemail = yes
hassip = yes
hasiax = yes
callwaiting = yes
threewaycalling = yes
callwaitingcallerid = yes
transfer = yes
canpark = yes
cancallforward = yes
callreturn = yes
callgroup = 1
pickupgroup = 1
nat = yes

[6001]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = kadoc
username = heykadoc
secret = perceval
context = work

[6002]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = karadoc
username = heykaradoc
secret = perceval
context = work
</pre>

Ensuite, on ajoute dans le fichier <pre>/etc/asterisk/extensions.conf :</pre>
<pre>
[work]
exten => _6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()
</pre>

On restart ensuite asterisk :
<pre>
service asterisk restart
</pre>

Puis on reload l'ensemble des fichiers afin qu'ils soient pris en compte :
<pre>
reload
</pre>

On cherche maintenant à savoir si notre configuration fonctionne. Pour cela, nous installons l'application CSipSimple sur deux téléphones Android sur lesquels nous configurons deux comptes.

Lorsque nous essayons de nous appeler, nous voyons que la communication fonctionne:
[[Fichier:15497641_10210148661905836_1314328693_n.jpg]]

Cahier 2016 groupe n°6

2017-01-03T13:52:28Z

Rlentieu : /* Réalisation 9ème semaine */

== Cahier des charges ==
=== Présentation du travail ===

==== Répartition du travail ====

{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/10)
| Connaissances du TP/ Recherche sur le routeur 3560E / Installation de la machine virtuelle
|-
! scope="row" | Séance 2 (10/10)
| Création des VLAN
|-
! scope="row" | Séance 3 (13/10)
| Création des VLAN / Création de la machine virtuelle
|-
! scope="row" | Séance 4 (24/10)
| Crackage de clé WEP
|-
! scope="row" | Séance 5 (07/11)
| Configuration Eeepc / Crackage clé WPA / Test de la configuration locale
|-
! scope="row" | Séance 6 (14/11)
| Configuration machine virtuelle / Configuration routeur ipv6 / interconnexion ipv4 et ipv6 / HSRP
|-
! scope="row" | Séance 7 (28/11)
| Configuration machine Virtuelle SSL / DNSSEC / Partition RAID5 / Cryptage des données
|-
! scope="row" | Séance 8 (05/12)
| Configuration Routeur pour Point d'Accès WIFI / Sécurisation Wifi par WPA2-EAP
|-
! scope="row" | Séance 9 (12/12)
| Configuration Asterisk et test de la VoIP
|}

===Réalisation 1ère semaine ===

Pour la première séance nous nous sommes chargés d'installer la machine virtuelle Xen à l'aide de la commande :
<pre>
xen-create-image --hostname=Kadoc --ip=193.48.57.166 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --gateway=193.48.57.172
--netmask=255.255.255.240 --dir=/usr/local/xen --passwd
</pre>
Ainsi, nous obtenons ce résultat:
<pre>
Installation Summary
---------------------
Hostname : Kadoc
Distribution : jessie
MAC Address : 00:16:3E:60:01:B1
IP Address(es) : 193.48.57.166
RSA Fingerprint : cf:03:35:4e:b7:f1:d4:f5:52:a1:d7:52:63:5d:83:57
Root Password : N/A
</pre>

===Réalisation 2ème semaine ===
=====VLANs=====
Durant les deux séances de cette semaine, nous avons réalisé la configuration locale du routeur 3560E, notamment la configuration des VLANs.

Pour cela, nous avons utilisé la communication série.
Lors du démarrage, nous devons le configurer :
<pre>
conf t
hostname Perceval
enable secret pasglop
</pre>

Nous passons maintenant à la configuration des VLANs:

Nous avons 11 VLANs à configurer :
* VLAN2 à VLAN11 : un pour chaque groupe
* VLAN12 : pour les machines virtuelles et donc le lien entre Cordouan et les commutateurs
* VLAN13 : pour l'interconnexion, c'est à dire le lien entre notre routeur et le routeur de l'école.

Pour la configuration, nous prendrons l'exemple du vlan 2.
Tout d'abord, nous affectons aux VLANs utiles:
<pre>
vlan 2
name Vlan2
exit
</pre>

Une fois le nom affecté :
<pre>
conf t
int Vlan2
ip address 10.60.2.2 255.255.255.0
exit
</pre>

=====Machine virtuelle=====

Tout d'abord, nous nous connectons sur le serveur cordouan:
<pre>
ssh root@cordouan.insecserv.deule.net
</pre>

Nous créons ensuite la machine avec tous les renseignements souhaités
<pre>
xen-create-image --hostname=Kadoc --ip=193.48.57.166 --netmask=255.255.255.240 --gateway=193.48.57.172
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie
</pre>
Enfin on démarre la machine virtuelle
<pre>
xl create /etc/xen/Kadoc.cfg
</pre>
Puis nous la lançons
<pre>
xl console Kadoc
</pre>

Lors de cette séance, nous avons aussi réservé notre nom de domaine sur Gandi : hamtaro.space

Nous avons également modifier le fichier de configuration de la VM en modifiant le fichier "/etc/xen/Kadoc.cfg" pour la taille mémoire 'de 128 à 512MB" ainsi que pour ajouter le bridge IMA5sc.

===Réalisation 3ème semaine ===
=====crackage clé WEP=====
1ere commande : airodump-ng --encrypt wep wlan2
BSSID PWR Beacons #data #/s CH MB ENC CIPHER AUTH ESSID
04:DA:D2:9C:50:56 -57 1 65 32 2 54e. WEP WEP cracotte07

La cible que nous avons choisie est "cracotte07", donc on utilise la commande suivante :

airodump-ng --essid cracotte07 --channel 2 -w testcrack wlan2

On obtient:

CH 2 ][ Elapsed: 3 mins ][ 2014-12-12 18:15
<pre>
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
04:DA:D2:9C:50:56 -55 6 505 9516 231 2 54e. WEP WEP cracotte07
</pre>
Le monitoring est donc lancé, nous pouvons passer au crackage :
aircrack-ng testcrack-01.cap

On obtient finalement la clé :

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:E4:44:44:44 ]
Decrypted correctly: 100%

===Réalisation 4ème semaine===

=====Configuration eeePC =====
''SSH:''

On modifie le fichier /etc/resolv.conf
<pre>
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
</pre>

Pour pouvoir se connecter en ssh il est nécessaire de modifier le ficher /etc/network/interfaces de la façon suivante :
rajouter les lignes :
<pre>
auto wlan2
iface wlan2 inet static
wireless mode-managed
wireless essid Wolverine // pour se connecter à la borne Wifi
wireless-key 0123456789 // mot de passe de la borne
address 172.26.79.22 // notre adresse
netmask 255.255.255.240
gateway 172.26.79.254
</pre>

''Intrusion par changement d'adresse MAC''
En changeant notre adresse MAC grâce à la commande
<pre>
ifconfig wlan2 down
ifconfig wlan2 hw ether 74:29:af:f3:fd:71
ifconfig wlan2 up
</pre>
On ne peut plus se connecter.

=====Crackage clé WPA=====

On effectue la même démarche que pour le crackage de la clé WEP pour :
<pre>
airodump-ng --encrypt wpa wlan1
</pre>
On choisit de cracker cracotte03
<pre>
airodump-ng -w out --encrypt wpa -c 13 --bssid 04:DA:D2:9C:50:52 wlan1
</pre>
On obtient le handshake 04:DA:D2:9C:50:52

On crée le dictionnaire grâce à la commande :
<pre>
crunch 8 8 0123456789 > dico.txt
</pre>
On lance ensuite :
<pre>
airodump-ng --essid cracotte03 -c 13 --bssid 04:DA:D2:9C:50:52 -w dump wlan1
</pre>
On décode ensuite le fichier dump grâce à la commande :
<pre>
aircrack-ng dump-01.cap -w dico.txt -l KEY
</pre>
Après un long moment on obtient le résultat, la clé WPA est
<pre>
12399903
</pre>

=====Test configuration routeur=====
Pour tester la configuration de notre routeur, il fallait le relier au commutateur qui devait être relié au serveur cordouan.
Or pour cela, il nous était impossible de le relier en filaire. Nous avons donc utilisé la fibre.
Nous avons donc dû utiliser un convertisseur de l'interface 10Gi en deux interfaces Gi.
Une fois cela effectué, nous pouvions relier la fibre au commutateur qui était lui-même relié au serveur Cordouan.
Il fallait seulement changer le mode access du port sur le commutateur et le configurer en Trunk.

Une fois cela effectué et bien configuré, nous parvenons à "pinger" notre routeur depuis notre machine virtuelle.

<pre>
# ping 193.48.57.172
PING 193.48.57.172 (193.48.57.172) 56(84) bytes of data.
64 bytes from 193.48.57.172: icmp_seq=1 ttl=255 time=6.23 ms
64 bytes from 193.48.57.172: icmp_seq=2 ttl=255 time=1.01 ms
64 bytes from 193.48.57.172: icmp_seq=3 ttl=255 time=19.8 ms
64 bytes from 193.48.57.172: icmp_seq=4 ttl=255 time=1.56 ms
64 bytes from 193.48.57.172: icmp_seq=5 ttl=255 time=8.55 ms
64 bytes from 193.48.57.172: icmp_seq=6 ttl=255 time=2.36 ms
^C
--- 193.48.57.172 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 1.018/6.593/19.818/6.495 ms
</pre>

===Réalisation 5ème semaine ===

=====Configuration machine virtuelle=====
Installation des packages ssh, apache2 et bind9.

Modification du fichier :
<pre>
/etc/bind/db.hamtaro.space
</pre>

<pre>
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.hamtaro.space. root.hamtaro.space (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN NS ns.hamtaro.space.
IN NS ns6.gandi.net.
IN MX 100 ns.hamtaro.space.

ns IN A 193.48.57.166
www IN A 193.48.57.166

</pre>

Modification du fichier :
<pre>
/etc/bind/named.conf.local
</pre>

<pre>
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "hamtaro.space" IN {
type master;
file "/etc/bind/db.hamtaro.space";
allow-transfer {217.70.177.40;};
};
</pre>

On va ensuite sur le site de Gandi pour modifier des informations.
Les Glue Records :
<pre>
'Nom du serveur' : ns.hamtaro.space
'IP' : 193.48.57.166
</pre>

Puis dans la rubrique modifier les serveurs DNS :
<pre>
'DNS1' : ns.hamtaro.space
'DNS2' : ns6.gandi.net
</pre>

Sécurisation de site web par certificat :

On tape la commande :
<pre>
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hamtaro.space.key -out hamtaro.space.csr
</pre>

Puis on remplis les champs demandés :
<pre>
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Nord
Locality Name (eg, city) []:Lille
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:hamtaro.space
</pre>

On se rend ensuite sur le site de Gandi et on rentre le contenu du fichier hamtaro.space.csr dans le champs CSR prévu à cet effet puis nous attendons la validation de notre certificat.

===== Configuration routeur=====
Configuration IPV6 des Vlan:
<pre>
ipv6 enable
ipv6 address 2001:660:4401:60XX::/64 eui-64
ipv6 nd prefix 2001:660:4401:60XX::/64 1000 900
</pre>

Avec les valeurs de XX variant de B0 à BA.
Pour le vlan130, cette valeur change : AA.

Interconnexion IPV4:
<pre>
router ospf 1
router-id 10.60.2.2
summary-address 10.60.0.0 255.255.0.0
summary-address 193.48.57.160 255.255.255.240
redistribute connected metric 30 subnets
network 192.168.222.0 0.0.0.7 area 1
</pre>

Interconnexion IPV6:
<pre>
ipv6 router rip tpima5sc
redistribute connected metric 1
redistribute static metric 1
redistribute rip 1 metric 1
</pre>

Une fois cela effectué, il faut que le vlan d'interconnexion prenne en compte ces modifications, il faut donc ajouter la commande :
<pre>
ipv6 rip tpima5sc enable
</pre>
Enfin, pour confirmer la configuration effectuée, nous affichons la table de routage ipv6 :
sh ipv6 route

On obtient alors le résultat suivant :
<pre>
IPv6 Routing Table - Default - 65 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, D - EIGRP, EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R ::/0 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:60::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6000::/56 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6002::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6003::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6004::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6005::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6006::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6007::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6008::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6009::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6011::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6013::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6014::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6015::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
R 2001:660:4401:6016::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, Vlan130
...
</pre>

On essaie ensuite de ping le site de google depuis la machine virtuelle. On obtient un résultat positif. Notre configuration est donc fonctionnelle.

===== Sécurisation du réseau par HSRP =====
Pour empêcher les pertes de transmission de paquets, il faut ajouter une passerelle sur chaque interface.
De plus il faut ajouter l'adresse du routeur virtuel sur le vlan des machines virtuelles à savoir : 193.48.57.173.
On a alors :
<pre>
interface Vlan12
ip address 193.48.57.172 255.255.255.240
standby 1 ip 193.48.57.173
standby 1 priority 110
standby 1 preempt
</pre>

Une fois cela effectué sur notre routeur mais aussi sur le routeur de Stéphane et Thomas (groupe 5), nous réussissons à pinger leurs interfaces virtuelles ainsi que les interfaces de la machine virtuelle.
Nous pouvons également voir lors de l'affichage de la configuration en standby que notre routeur est considéré comme local tandis que le leur est en standby. La ligne traitant de la priorité fonctionne donc et permet la redondance du système.

===Réalisation 6ème semaine ===
====Suite Sécurisation SSL====
Après avoir obtenu notre certificat SSL sur le site GANDI, nous pouvons copier les fichiers utiles dans le dossier ssl:
<pre>
root@Flash:/etc/bind# cp certificat.crt /etc/ssl/certs/hamtaro.space.crt
root@Flash:/etc/bind# cp hamtaro.space.key /etc/ssl/private/hamtaro.space.key
root@Flash:/etc/bind# cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem
</pre>

Nous créons le fichier 000-hamtaro.space-ssl.conf dans le dossier "apache2/sites-available" afin de pouvoir joindre notre nom de serveur et Apache:
<pre>
#NameVirtualHost *:443
<VirtualHost 193.48.57.166:443>
ServerName www.hamtaro.space
ServerAlias hamtaro.space
DocumentRoot /var/www/www.hamtaro.space/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/hamtaro.space.crt
SSLCertificateKeyFile /etc/ssl/private/hamtaro.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem
SSLVerifyClient None
</VirtualHost>
<Directory /var/www/www.hamtaro.space>
Require all granted
</Directory>
ServerName "hamtaro.space"
</pre>

Enfin, nous devons modifier le fichier ports.conf afin que le serveur Apache écoute sur le port 443.
<pre>
Listen 80 443

<IfModule ssl_module>
Listen 443
</IfModule>

#<IfModule mod_gnutls.c>
# Listen 443
#</IfModule>

#<IfModule mod_ssl.c>
# Listen 443
#NameVirtualHost *:443
#</IfModule>
</pre>

Nous pouvons désormais activer le module SSL de apache :
<pre>a2enmod ssl</pre>

Puis nous pouvons activer notre certificat pour notre site :
<pre>
a2ensite 000-hamtaro.space-ssl.conf
Enabling site 000-hamtaro.space-ssl.
service apache2 reload //afin de charger la nouvelle configuration.
</pre>

Nous pouvons donc maintenant voir que notre site est sécurisé en allant sur https://www.hamtaro.space 
Il y a en effet le cadenas vert symbolisant cela:

[[Fichier:Screensecuresite.png]]

====Sécurisation par DNSSEC====

Dans un premier temps on va modifier le fichier /etc/bind/named.conf.options et rajouter la ligne :
<pre>
dnssec-enable yes
</pre>

Nous devons maintenant générer les clés (fichiers KSK et ZSK) que nous utiliserons afin de signer les zones:
<pre>
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hamtaro.space
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hamtaro.space
</pre>

Nous les plaçons dans un dossier nommé hamtaro.space.dnssec.

Nous modifions ensuite le fichier db.hamtaro.space afin d'inclure ces deux clés:
<pre>
$include /etc/bind/hamtaro.space.dnssec/hamtaro.space-ksk.key
$include /etc/bind/hamtaro.space.dnssec/hamtaro.space-zsk.key
</pre>

Il nous faut maintenant signer la zone :
<pre> dnssec-signzone -o hamtaro.space -k hamtaro.space-ksk ../db.hamtaro.space hamtaro.space-zsk
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.hamtaro.space.signed
</pre>

Nous ajoutons ensuite le DNSSEC sur Gandi :
[[Fichier:dnssecKadoc.png]]

On peut ensuite vérifier que notre DNSSEC est bien sécurisé :
<pre>
root@Kadoc:/etc/bind# dig DNSKEY hamtaro.space @localhost

; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> DNSKEY hamtaro.space @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5615
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;hamtaro.space. IN DNSKEY

;; AUTHORITY SECTION:
hamtaro.space. 604800 IN SOA ns.hamtaro.space. root.hamtaro.space.hamtaro.space. 3 604800 86400 2419200 604800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 28 13:21:10 CET 2016
;; MSG SIZE rcvd: 100

</pre>

====Partition RAID5====
Pour assurer la sécurisation des données, nous configurons trois partitions de volumes logiques sur la machine virtuelle:

<pre>
lvcreate -L 1G -n /dev/virtual/ima5-lapoulette
lvcreate -L 1G -n /dev/virtual/ima5-Karadoc
lvcreate -L 1G -n /dev/virtual/ima5-pelinord
</pre>

Puis nous modifions le fichier de configuration de notre machine virtuelle :
<pre>
disk = [
'file:/usr/local/xen/domains/Kadoc/disk.img,xvda2,w',
'file:/usr/local/xen/domains/Kadoc/swap.img,xvda1,w',
'phy:/dev/virtual/ima5-pelinord,xvdb,w',
'phy:/dev/virtual/ima5-Karadoc,xvdc,w',
'phy:/dev/virtual/ima5-lapoulette,xvdd,w',
]
</pre>

Nous pouvons maintenant relancer notre machine virtuelle.
Nous pouvons y créer le RAID5 avec les 3 partitions:
<pre> mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdb /dev/xvdc /dev/xvdd </pre>

On peut ensuite voir le détail de la configuration :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 12:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Nov 29 13:18:04 2016
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : 90156134:39a740fa:0de8c29d:486dce2c
Events : 22

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
1 202 32 1 active sync /dev/xvdc
3 202 48 2 active sync /dev/xvdd
</pre>

Nous devons ensuite sauvegarder cette configuration afin de garder notre md0, pour cela:
<pre> mdadm --detail --scan >> /etc/mdadm/mdadm.conf </pre>
puis nous pouvons copier les données sur le RAID5:
<pre>
root@Kadoc:~# mkfs /dev/md0
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 523776 4k blocks and 131072 inodes
Filesystem UUID: 2703e116-ed2c-46fe-964a-928be0b34cd6
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
</pre>
Puis:
<pre>
root@Kadoc:~# mount /dev/md0 /mnt
[ 702.230079] EXT4-fs (md0): mounting ext2 file system using the ext4 subsystem
[ 702.309734] EXT4-fs (md0): mounted filesystem without journal. Opts: (null)
</pre>

Nous allons maintenant voir ce qu'il se passe lorsque l'on enlève une des partitions à la machine.
Nous redémarrons la machine virtuelle et nous affichons le détail :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 12:23:50 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 2
Persistence : Superblock is persistent

Update Time : Tue Nov 29 12:43:56 2016
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : b333670e:27b24fbe:045a7e98:c7eafb49
Events : 14

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
2 0 0 2 removed
2 202 48 2 active sync /dev/xvdd
</pre>

Nous voyons donc bien qu'une partition a été enlevée.
Pour réparer cela,
<pre>
mdadm --set-faulty /dev/md0 /dev/xvdc
mdadm --remove /dev/md0 /dev/xvdc
</pre>

La partition est bien supprimée:
<pre>
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdb[0] xvdd[3]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
</pre>

On remet la partition:
<pre>mdadm --add /dev/md0 /dev/xvdc</pre>

On peut ensuite suivre l'avancement de la restauration:
<pre>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===========>.........] recovery = 56.9% (596964/1047552) finish=0.2min speed=29848K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=============>.......] recovery = 66.9% (701992/1047552) finish=0.1min speed=29249K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===============>.....] recovery = 75.0% (786728/1047552) finish=0.1min speed=29138K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=================>...] recovery = 85.1% (892660/1047552) finish=0.0min speed=29755K/sec

unused devices: <none>
root@Kadoc:/dev# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 99.6% (1044732/1047552) finish=0.0min speed=30465K/sec

unused devices: <none>
root@Kadoc:/dev# [ 156.292138] md: md0: recovery done.
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>
</pre>

Enfin, on retrouve la configuration initiale :
<pre>
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
root@Kadoc:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Nov 29 13:06:20 2016
Raid Level : raid5
Array Size : 2095104 (2046.34 MiB 2145.39 MB)
Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Nov 29 13:18:04 2016
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Name : Kadoc:0 (local to host Kadoc)
UUID : 90156134:39a740fa:0de8c29d:486dce2c
Events : 22

Number Major Minor RaidDevice State
0 202 16 0 active sync /dev/xvdb
1 202 32 1 active sync /dev/xvdc
3 202 48 2 active sync /dev/xvdd
</pre>

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

Pour cette partie, nous commençons par installer lvm2, Gparted ainsi que cryptsetup sur notre eeePc.
Nous voulons une seule partition sur la carte SD. Pour cela on utilise:
<pre>
fdisk /dev/mmcblk1
</pre>
On créé alors une partition primaire sur tout l'espace disponible de la carte.

Une fois cette partition créée, elle n'est pas cryptée, nous allons donc maintenant utiliser le cryptsetup:

<pre>
cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
</pre>
Cette commande permet de formatter la partition au type Luks avec un chiffrement AES avec un algorithme de hâchage SHA256.
On doit aussi choisir un mot de passe pour crypter la partition.

Pour voir l'état du conteneur, on peut utiliser la commande :
<pre>
root@lamproie:~# cryptsetup luksDump /dev/mmcblk1
LUKS header information for /dev/mmcblk1

Version: 1
Cipher name: aes
Cipher mode: cbc-plain
Hash spec: sha256
Payload offset: 4096
MK bits: 256
MK digest: b9 ed bc f9 68 3c ac 64 d4 3b a4 44 5b 48 38 b2 d1 b4 7d 87
MK salt: 8a a5 f6 38 a7 08 fe 6b 90 7d 88 79 10 fc 70 15
95 e0 67 82 ee 34 fe 87 23 3e 2a 77 f7 ed cf 35
MK iterations: 125750
UUID: 07082d69-6117-42f8-81a3-695d1ea8e5df

Key Slot 0: ENABLED
Iterations: 1007873
Salt: 98 b5 bd 00 ca 5b 70 81 62 50 8d 5f ba ea d9 4c
35 38 70 bf 09 0b da 95 51 cb 81 c0 35 2d fe da
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
</pre>

On ouvre ensuite notre partition cryptée:
<pre> cryptsetup luksOpen /dev/mmcblk1 kadoc </pre>

On peut ainsi ajouter le système de fichiers à notre partition cryptée:
<pre>mkfs.ext3 /dev/mapper/kadoc</pre>

Ensuite, nous pouvons monter la partition pour pouvoir y écrire. Nous pouvons aussi la démonter lorsque nos fichiers seront copiés:
<pre>
mount -t ext3 /dev/mapper/kadoc /mnt/ //pour monter la partition.

umount /mnt/ //pour démonter la partition.
</pre>

Enfin pour encrypter à nouveau cette partition, on utilise la commande:
<pre> cryptsetup luksClose kadoc </pre>

On utilise la commande <pre> gparted /dev/mmcblk1 </pre> afin de voir la partition, on obtient ceci:

[[Fichier:Screencrypt.png]]

On voit donc que les informations de cette partition ne sont pas disponibles à moins d'avoir la clé.

===Réalisation 7ème semaine ===
Lors de cette semaine nous avons pu connecter le points d'accès Wifi de Valentin et Alexandre sur le commutateur de la salle E304. Pour cela, nous avons dû configurer un vlan1 sur le routeur qui prend l'adresse 10.60.1.3.
Ainsi, nous avons pu nous trouver ce point d'accès qui a pris l'adresse 10.60.1.6.
Nous avions ainsi les deux points d'accès qui étaient connectés dans chaque salle :
En E304 : avec l'adresse 10.60.1.6 et en E306 : 10.60.1.2.

Une fois cela fait, nous pouvons passer à la sécurisation Wifi par WPA2-EAP.

=====Sécurisation Wifi par WPA2-EAP=====
Nous allons utiliser cette méthode afin de créer le point d'accès que nous avons mentionné plus haut et d'en sécuriser la connexion.
Tout d'abord, nous devons créer le serveur FreeRadius:
Nous devons tout d'abord modifier certains fichiers de configuration du serveur :
dans le fichier ''eap.conf'' nous devons modifier une ligne afin de modifier le protocole d'identification :
<pre> default_eap_type = peap </pre>

Une fois cela fait, nous devons modifier le fichier ''clients.conf'', ce qui nous permettra de configurer nos points d'accès Wifi:
<pre>

client E304 {
ipaddr = 10.60.1.6
secret = kadoc
shortname = wifi1
}

client E306 {
ipaddr = 10.60.1.2
secret = kadoc
shortname = wifi2
}
</pre>
Nous avons ainsi configuré les deux points d'accès.

Enfin, nous devons ajouter une ligne au fichier users qui va nous permettre de créer un nouvel utilisateur pour l'identification:
<pre> karadoc Cleartext-Password := "perceval" </pre>

Une fois cela fait, nous pouvons lancer notre serveur FreeRadius.

Nous allons maintenant passer à la configuration du point d'accès afin d'avoir un accès sécurisé avec notre serveur précédemment détaillé:
<pre>
telnet 10.60.1.6

...

conf t

aaa new-model
aaa authentication login eap_kadoc group radius_kadoc
radius-server host 193.48.57.166 auth-port 1812 acct-port 1813 key kadoc
aaa group server radius radius_kadoc
server 193.48.57.166 auth-port 1812 acct-port 1813

exit

dot11 ssid SSID_KADOC
vlan 7
authentication open eap eap_kadoc
authentication network-eap eap_kadoc
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 7 mode ciphers aes-ccm tkip
ssid SSID_KADOC

exit

interface Dot11Radio0.7
encapsulation dot1Q 7
no ip route-cache
bridge-group 7
bridge-group 7 subscriber-loop-control
bridge-group 7 spanning-disabled
bridge-group 7 block-unknown-source
no bridge-group 7 source-learning
no bridge-group 7 unicast-flooding

exit

interface GigabitEthernet0.7
encapsulation dot1Q 7
bridge-group 7

exit

exit

write
</pre>

La borne est maintenant configurée, il ne nous reste plus qu'à nous y connecter.

Pour cela, nous devons encore modifier le wlan0 de l'eeepc.
Nous modifions donc le fichier /etc/network/interfaces :
<pre>
auto wlan0
iface wlan0 inet static
address 10.60.7.7
netmask 255.255.255.0
gateway 10.60.7.1
wpa-ssid KADOC
wpa-key-mgmt WPA-EAP
wpa-identity karadoc
wpa-password perceval
</pre>

Une fois cela fait, nous pouvons nous connecter sur le point d'accès de la salle E304. Pour se connecter sur celui de la E306, il faudrait faire la même configuration sur ce point d'accès.
Nous avons réussi à nous connecter à ce point d'accès en rentrant une adresse IP valide à la main. Pour rendre cela automatique, nous devrons installer un serveur DHCP sur notre Eeepc qui nous permettre d'attribuer une adresse IP à notre smartphone

===Réalisation 9ème semaine ===

Nous avons dans un premier temps installer Asterisk
<pre>
apt-get install asterisk
</pre>

Nous avons ensuite configuré le fichier <pre> /etc/asterisk/users.conf </pre> en y ajoutant :
<pre>
[general]
hasvoicemail = yes
hassip = yes
hasiax = yes
callwaiting = yes
threewaycalling = yes
callwaitingcallerid = yes
transfer = yes
canpark = yes
cancallforward = yes
callreturn = yes
callgroup = 1
pickupgroup = 1
nat = yes

[6001]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = kadoc
username = heykadoc
secret = perceval
context = work

[6002]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = karadoc
username = heykaradoc
secret = perceval
context = work
</pre>

Ensuite, on ajoute dans le fichier <pre>/etc/asterisk/extensions.conf :</pre>
<pre>
[work]
exten => _6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()
</pre>

On restart ensuite asterisk :
<pre>
service asterisk restart
</pre>

Puis on reload l'ensemble des fichiers afin qu'ils soient pris en compte :
<pre>
reload
</pre>

On cherche maintenant à savoir si notre configuration fonctionne. Pour cela, nous installons l'application CSipSimple sur deux téléphones Android sur lesquels nous configurons deux comptes.

Lorsque nous essayons de nous appeler, nous voyons que la communication fonctionne:
[[Fichier:15497641_10210148661905836_1314328693_n.jpg]]

Gant de Boxe connecté

2017-01-03T10:09:34Z

Rlentieu : /* Matériel utilisé */

Gant de Boxe connecté

2017-01-03T10:08:17Z

Rlentieu : /* Matériel utilisé */

Gant de Boxe connecté

2017-01-03T10:07:44Z

Rlentieu : /* 1ère Séance */

Gant de Boxe connecté

2017-01-03T10:06:32Z

Rlentieu : /* Suivi de réalisation */

Gant de Boxe connecté

2017-01-03T10:01:58Z

Rlentieu : /* Suivi de réalisation */

Gant de Boxe connecté

2017-01-03T09:59:24Z

Rlentieu : /* Description */

Gant de Boxe connecté

2017-01-03T09:58:56Z

Rlentieu : /* Matériel utilisé */

Gant de Boxe connecté

2017-01-03T09:57:36Z

Rlentieu :

Gant de Boxe connecté

2017-01-03T09:36:40Z

Rlentieu : /* Matériel utilisé */

=Présentation du sujet =
=Matériel utilisé=
par gant:

Accéléromètre

capteurs de pression flexibles carrés (x4)

arduino + dongle bluetooth

dongle bluetooth (pour PC)

paire de gants

=Suivi de réalisation=
=Poster=

Gant de Boxe connecté

2017-01-03T09:33:04Z

Rlentieu : /* Matériel utilisé */

=Présentation du sujet =
=Matériel utilisé=
Accéléromètre

capteurs de pression flexibles carrés (x4)

arduino + dongle bluetooth

dongle bluetooth (pour PC)

paire de gants

=Suivi de réalisation=
=Poster=

Gant de Boxe connecté

2017-01-03T09:32:45Z

Rlentieu : /* Matériel utilisé */

=Présentation du sujet =
=Matériel utilisé=
Accéléromètre
capteurs de pression flexibles carrés (x4)
arduino + dongle bluetooth
dongle bluetooth (pour PC)
paire de gants

=Suivi de réalisation=
=Poster=

Gant de Boxe connecté

2017-01-03T09:30:04Z

Rlentieu :

=Présentation du sujet =
=Matériel utilisé=
=Suivi de réalisation=
=Poster=