Wiki de Projets IMA - Contributions de l’utilisateur [fr]

Cahier 2016 groupe n°6

2016-12-14T09:19:30Z

Mszwecho : /* 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>

Et on peut observer que la communication fonctionne :

[[Fichier:15497641_10210148661905836_1314328693_n.jpg]]

Fichier:15497641 10210148661905836 1314328693 n.jpg

2016-12-14T09:18:05Z

Mszwecho :

2016-06-11T16:32:05Z

Mszwecho : /* Applications */

= Summary =

This article deals with the benefits of using elastic soft Robots. For now, the approaches to create them are made by inspiration from nature but with their high elasticity it's really hard to control them. So it's necessary to know how to modelize their movement and that's what the article explain with the Finite Element Method ( FEM ) in order to model the deformations that are the cause of a mechanical coupling.
 

So, in first the author insist on the difficulty to anticipate the movement because of the infinite number of degrees of freedom, and also on the several advances made on this subject by other scientists. But to control a soft robot he explains that we need a real-time computation and thanks to algorithms adapted to GPU, the computation time can be reduced.
 
After that he explains the principle of the FEM. Before everything he needed to know the constitutive law of the soft material by making stress-strain response under tension experiments and he found with a linear regression that the strain/stress ratio is approximatively linear that will reduce the time of online execution of the FEM.
But when he assembled the possible rotation in the model is no more linear but it's still possible to compute it with an C++ implementation thanks to the open-source framework SOFA. To have the FEM model we need to compute the following linearization of the internal forces. 
 
But, in addition of the FEM we add a new method that refer new directions in the (J^T) matrix and after that we have to resolve the structure.
 The next step is to find λ by using the constraint-based solver that allow us to find the final configuration : 
xt = xfree + K^(−1) * J^T * λ. 
Where plus '''definir'''
 
So it's possible to obtain actuator model by studying its physical chracteristic to finally knowing the final model.
 
The next step after knowing the model is to achieve to create the control algorithm.
For that we need to know the mechanical coupling between effector and actuator and between actuator to have kinematic equations to build the position control with Gauss Seidel in order to reduce the shift between between actual and desired position. The author also explains that we can add external contact constraints imposed by the nearby object in the Gauss Seidel algortihm to improve the accuracy.
 
In conclusion, he finishes by showing us two examples of this work : the first one is a mathematics example by simulate some deplacements and check the accuracy with and without collision. The second one is a test on a deformable robot to validate the approach.

= Main contribution =
This article has the objective to present a new method for the control of Soft Robots with elastic behavior. 
The main contribution of this project is the use of the Finite Element Method with the computation in real time for the control of this robot and also by using Lagrange multipliers at the end of effector's position.
 It's also showing that it's possible to modelize and to control the movement of a soft robot but also to try to prove that an accomplishable method is to use the Gauss Seidel method by giving a mathematical model and by doing experiments with a 3D silicone made robot that obtain a maximum error of 2.9 mm that prove that the FEM method can be really accurate.
 This work also open new possibilities for several future work with the objective to improve the control of this kind of robot especially when they are in contact with soft object because until now experiments are done with "hard" objects.

= Applications =

This work can be the opening of several applications for the future in the medical field especially in surgery.
 Because for example when you're doing an operation you put some rigid tool in the patient's body and the surgeons spend their time to avoid any contact with organs and tissues. As soon as they touch them, they damage them. So with the use of soft robot we can allow a more secure way to doing it. 
But we can also imagine the creation of a soft exoskeleton to improve the comfort of disabled compare to today's solutions or also a new way to create better robotic organs for example. 
Because when researchers in robotics want to find a way to make their robots indestructible to avoid damage when they can't avoid collision, this new kind of robots can engage the environment without damage the robot or anything around it that is really important in a time when robots are way more present in our houses.
 An other thing is because of their soft structure, elastic robot are way more resistant than hard robot and less sensitive to hot or cold temperature so they are more capable to resist to extreme conditions

InitRech 2015/2016, sujet 1

2016-06-11T15:31:33Z

Mszwecho : /* Main contribution */

InitRech 2015/2016, sujet 1

2016-06-11T09:51:39Z

Mszwecho : /* Main contribution */

InitRech 2015/2016, sujet 1

2016-06-11T09:45:41Z

Mszwecho : /* Summary */

InitRech 2015/2016, sujet 1

2016-06-10T21:24:14Z

Mszwecho : /* Summary */