Cahier 2016 groupe n°6 : Différence entre versions
m (→Sécurisation Wifi par WPA2-EAP) |
m (→Suite Sécurisation SSL) |
||
| (4 révisions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 2 : | Ligne 2 : | ||
=== Présentation du travail === | === 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 ==== | ==== Répartition du travail ==== | ||
| Ligne 406 : | Ligne 409 : | ||
Après avoir obtenu notre certificat SSL sur le site GANDI, nous pouvons copier les fichiers utiles dans le dossier ssl: | Après avoir obtenu notre certificat SSL sur le site GANDI, nous pouvons copier les fichiers utiles dans le dossier ssl: | ||
<pre> | <pre> | ||
| − | root@ | + | root@Kadoc:/etc/bind# cp certificat.crt /etc/ssl/certs/hamtaro.space.crt |
| − | root@ | + | root@Kadoc:/etc/bind# cp hamtaro.space.key /etc/ssl/private/hamtaro.space.key |
| − | root@ | + | root@Kadoc:/etc/bind# cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem |
</pre> | </pre> | ||
| Ligne 928 : | Ligne 931 : | ||
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 | 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". | 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 === | ===Réalisation 9ème semaine === | ||
| Ligne 997 : | Ligne 1 002 : | ||
Lorsque nous essayons de nous appeler, nous voyons que la communication fonctionne: | Lorsque nous essayons de nous appeler, nous voyons que la communication fonctionne: | ||
| − | [[Fichier:15497641_10210148661905836_1314328693_n.jpg]] | + | [[Fichier:15497641_10210148661905836_1314328693_n.jpg||400px||center]] |
Version actuelle datée du 6 janvier 2017 à 11:12
Sommaire
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:
Répartition du travail
| Séance 1 (03/10) | Connaissances du TP/ Recherche sur le routeur 3560E / Installation de la machine virtuelle |
|---|---|
| Séance 2 (10/10) | Création des VLAN |
| Séance 3 (13/10) | Création des VLAN / Création de la machine virtuelle |
| Séance 4 (24/10) | Crackage de clé WEP |
| Séance 5 (07/11) | Configuration Eeepc / Crackage clé WPA / Test de la configuration locale |
| Séance 6 (14/11) | Configuration machine virtuelle / Configuration routeur ipv6 / interconnexion ipv4 et ipv6 / HSRP |
| Séance 7 (28/11) | Configuration machine Virtuelle SSL / DNSSEC / Partition RAID5 / Cryptage des données |
| Séance 8 (05/12) | Configuration Routeur pour Point d'Accès WIFI / Sécurisation Wifi par WPA2-EAP |
| 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 :
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
Ainsi, nous obtenons ce résultat:
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
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 :
conf t hostname Perceval enable secret pasglop
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:
vlan 2 name Vlan2 exit
Une fois le nom affecté :
conf t int Vlan2 ip address 10.60.2.2 255.255.255.0 exit
Machine virtuelle
Tout d'abord, nous nous connectons sur le serveur cordouan:
ssh root@cordouan.insecserv.deule.net
Nous créons ensuite la machine avec tous les renseignements souhaités
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
Enfin on démarre la machine virtuelle
xl create /etc/xen/Kadoc.cfg
Puis nous la lançons
xl console Kadoc
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
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
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
RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys
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 :
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
Intrusion par changement d'adresse MAC En changeant notre adresse MAC grâce à la commande
ifconfig wlan2 down ifconfig wlan2 hw ether 74:29:af:f3:fd:71 ifconfig wlan2 up
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 :
airodump-ng --encrypt wpa wlan1
On choisit de cracker cracotte03
airodump-ng -w out --encrypt wpa -c 13 --bssid 04:DA:D2:9C:50:52 wlan1
On obtient le handshake 04:DA:D2:9C:50:52
On crée le dictionnaire grâce à la commande :
crunch 8 8 0123456789 > dico.txt
On lance ensuite :
airodump-ng --essid cracotte03 -c 13 --bssid 04:DA:D2:9C:50:52 -w dump wlan1
On décode ensuite le fichier dump grâce à la commande :
aircrack-ng dump-01.cap -w dico.txt -l KEY
Après un long moment on obtient le résultat, la clé WPA est
12399903
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.
# 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
Réalisation 5ème semaine
Configuration machine virtuelle
Installation des packages ssh, apache2 et bind9.
Modification du fichier :
/etc/bind/db.hamtaro.space
; ; 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
Modification du fichier :
/etc/bind/named.conf.local
//
// 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;};
};
On va ensuite sur le site de Gandi pour modifier des informations. Les Glue Records :
'Nom du serveur' : ns.hamtaro.space 'IP' : 193.48.57.166
Puis dans la rubrique modifier les serveurs DNS :
'DNS1' : ns.hamtaro.space 'DNS2' : ns6.gandi.net
Sécurisation de site web par certificat :
On tape la commande :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hamtaro.space.key -out hamtaro.space.csr
Puis on remplis les champs demandés :
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
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:
ipv6 enable ipv6 address 2001:660:4401:60XX::/64 eui-64 ipv6 nd prefix 2001:660:4401:60XX::/64 1000 900
Avec les valeurs de XX variant de B0 à BA. Pour le vlan130, cette valeur change : AA.
Interconnexion IPV4:
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
Interconnexion IPV6:
ipv6 router rip tpima5sc redistribute connected metric 1 redistribute static metric 1 redistribute rip 1 metric 1
Une fois cela effectué, il faut que le vlan d'interconnexion prenne en compte ces modifications, il faut donc ajouter la commande :
ipv6 rip tpima5sc enable
Enfin, pour confirmer la configuration effectuée, nous affichons la table de routage ipv6 :
sh ipv6 route
On obtient alors le résultat suivant :
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
...
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 :
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
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:
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
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:
#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"
Enfin, nous devons modifier le fichier ports.conf afin que le serveur Apache écoute sur le port 443.
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>
Nous pouvons désormais activer le module SSL de apache :
a2enmod ssl
Puis nous pouvons activer notre certificat pour notre site :
a2ensite 000-hamtaro.space-ssl.conf Enabling site 000-hamtaro.space-ssl. service apache2 reload //afin de charger la nouvelle configuration.
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:
Sécurisation par DNSSEC
Dans un premier temps on va modifier le fichier /etc/bind/named.conf.options et rajouter la ligne :
dnssec-enable yes
Nous devons maintenant générer les clés (fichiers KSK et ZSK) que nous utiliserons afin de signer les zones:
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
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:
$include /etc/bind/hamtaro.space.dnssec/hamtaro.space-ksk.key $include /etc/bind/hamtaro.space.dnssec/hamtaro.space-zsk.key
Il nous faut maintenant signer la zone :
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
Nous ajoutons ensuite le DNSSEC sur Gandi :
On peut ensuite vérifier que notre DNSSEC est bien sécurisé :
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
Partition RAID5
Pour assurer la sécurisation des données, nous configurons trois partitions de volumes logiques sur la machine virtuelle:
lvcreate -L 1G -n /dev/virtual/ima5-lapoulette lvcreate -L 1G -n /dev/virtual/ima5-Karadoc lvcreate -L 1G -n /dev/virtual/ima5-pelinord
Puis nous modifions le fichier de configuration de notre machine virtuelle :
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',
]
Nous pouvons maintenant relancer notre machine virtuelle. Nous pouvons y créer le RAID5 avec les 3 partitions:
mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdb /dev/xvdc /dev/xvdd
On peut ensuite voir le détail de la configuration :
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
Nous devons ensuite sauvegarder cette configuration afin de garder notre md0, pour cela:
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
puis nous pouvons copier les données sur le RAID5:
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
Puis:
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)
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 :
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
Nous voyons donc bien qu'une partition a été enlevée. Pour réparer cela,
mdadm --set-faulty /dev/md0 /dev/xvdc mdadm --remove /dev/md0 /dev/xvdc
La partition est bien supprimée:
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_]
On remet la partition:
mdadm --add /dev/md0 /dev/xvdc
On peut ensuite suivre l'avancement de la restauration:
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>
Enfin, on retrouve la configuration initiale :
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
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:
fdisk /dev/mmcblk1
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:
cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
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 :
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
On ouvre ensuite notre partition cryptée:
cryptsetup luksOpen /dev/mmcblk1 kadoc
On peut ainsi ajouter le système de fichiers à notre partition cryptée:
mkfs.ext3 /dev/mapper/kadoc
Ensuite, nous pouvons monter la partition pour pouvoir y écrire. Nous pouvons aussi la démonter lorsque nos fichiers seront copiés:
mount -t ext3 /dev/mapper/kadoc /mnt/ //pour monter la partition. umount /mnt/ //pour démonter la partition.
Enfin pour encrypter à nouveau cette partition, on utilise la commande:
cryptsetup luksClose kadocOn utilise la commande
gparted /dev/mmcblk1afin de voir la partition, on obtient ceci:
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 :
default_eap_type = peap
Une fois cela fait, nous devons modifier le fichier clients.conf, ce qui nous permettra de configurer nos points d'accès Wifi:
client E304 {
ipaddr = 10.60.1.6
secret = kadoc
shortname = wifi1
}
client E306 {
ipaddr = 10.60.1.2
secret = kadoc
shortname = wifi2
}
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:
karadoc Cleartext-Password := "perceval"
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é:
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
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 :
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
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
apt-get install asteriskNous avons ensuite configuré le fichier
/etc/asterisk/users.confen y ajoutant :
[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 = workEnsuite, on ajoute dans le fichier
/etc/asterisk/extensions.conf :
[work]
exten => _6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()
On restart ensuite asterisk :
service asterisk restart
Puis on reload l'ensemble des fichiers afin qu'ils soient pris en compte :
reload
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:
