Cahier 2016 groupe n°6 : Différence entre versions

De Wiki d'activités IMA
m (→‎Répartition du travail)
m (→‎Suite Sécurisation SSL)
 
(100 révisions intermédiaires par 2 utilisateurs 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 19 : Ligne 22 :
 
  |-
 
  |-
 
  ! scope="row" | Séance 5 (07/11)
 
  ! scope="row" | Séance 5 (07/11)
−
  | Configuration Eepc / Test de la configuration locale
+
  | Configuration Eeepc / Crackage clé WPA / Test de la configuration locale
 
  |-
 
  |-
 
  ! scope="row" | Séance 6 (14/11)
 
  ! scope="row" | Séance 6 (14/11)
−
  |  
+
  | Configuration machine virtuelle / Configuration routeur ipv6 / interconnexion ipv4 et ipv6 / HSRP
 
  |-
 
  |-
−
  ! scope="row" | Séance 7 (21/11)
+
  ! scope="row" | Séance 7 (28/11)
−
  |  
+
  | Configuration machine Virtuelle SSL / DNSSEC / Partition RAID5 / Cryptage des données
 
  |-
 
  |-
−
  ! scope="row" | Séance 8 (28/11)
+
  ! scope="row" | Séance 8 (05/12)
−
  |  
+
  | Configuration Routeur pour Point d'Accès WIFI / Sécurisation Wifi par WPA2-EAP
 
  |-
 
  |-
 +
! scope="row" | Séance 9 (12/12)
 +
| Configuration Asterisk et test de la VoIP
 
  |}
 
  |}
  
Ligne 95 : Ligne 100 :
 
Nous créons ensuite la machine avec tous les renseignements souhaités
 
Nous créons ensuite la machine avec tous les renseignements souhaités
 
<pre>
 
<pre>
−
   xen-create-image --hostname=Kadoc --ip=193.48.57.172 --netmask=255.255.255.240 --gateway=193.48.57.172
+
   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
 
   --dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie
 
</pre>
 
</pre>
Ligne 112 : Ligne 117 :
  
 
===Réalisation 3ème semaine ===
 
===Réalisation 3ème semaine ===
−
Lors de cette séance : crackage clé WEP :
+
=====crackage clé WEP=====
−
 
 
 
1ere commande : airodump-ng --encrypt wep wlan2
 
1ere commande : airodump-ng --encrypt wep wlan2
 
       BSSID              PWR      Beacons  #data #/s CH MB  ENC CIPHER AUTH ESSID
 
       BSSID              PWR      Beacons  #data #/s CH MB  ENC CIPHER AUTH ESSID
Ligne 139 : Ligne 143 :
 
===Réalisation 4ème semaine===
 
===Réalisation 4ème semaine===
  
−
Configuration eeePC  
+
=====Configuration eeePC =====
−
SSH
+
''SSH:''
  
 
On modifie le fichier /etc/resolv.conf
 
On modifie le fichier /etc/resolv.conf
Ligne 162 : Ligne 166 :
 
</pre>
 
</pre>
  
−
Intrusion par changement d'adresse MAC
+
''Intrusion par changement d'adresse MAC''
 
En changeant notre adresse MAC grâce à la commande  
 
En changeant notre adresse MAC grâce à la commande  
 
<pre>
 
<pre>
Ligne 171 : Ligne 175 :
 
On ne peut plus se connecter.
 
On ne peut plus se connecter.
  
−
Crackage clé WPA :
+
=====Crackage clé WPA=====
  
−
On effectue la même démarche que pour le craquage de la clé WEP pour :
+
On effectue la même démarche que pour le crackage de la clé WEP pour :
 
<pre>
 
<pre>
 
airodump-ng --encrypt wpa wlan1
 
airodump-ng --encrypt wpa wlan1
Ligne 187 : Ligne 191 :
 
crunch 8 8 0123456789 > dico.txt  
 
crunch 8 8 0123456789 > dico.txt  
 
</pre>
 
</pre>
−
Onlance ensuite :  
+
On lance ensuite :  
 
<pre>
 
<pre>
 
airodump-ng --essid cracotte03 -c 13 --bssid 04:DA:D2:9C:50:52 -w dump wlan1
 
airodump-ng --essid cracotte03 -c 13 --bssid 04:DA:D2:9C:50:52 -w dump wlan1
Ligne 195 : Ligne 199 :
 
aircrack-ng dump-01.cap -w dico.txt -l KEY
 
aircrack-ng dump-01.cap -w dico.txt -l KEY
 
</pre>
 
</pre>
 +
Après un long moment on obtient le résultat, la clé WPA est
 +
<pre>
 +
12399903
 +
</pre>
 +
 +
=====Test configuration routeur=====
 +
Pour tester la configuration de notre routeur, il fallait le relier au commutateur qui devait être relié au serveur cordouan.
 +
Or pour cela, il nous était impossible de le relier en filaire. Nous avons donc utilisé la fibre.
 +
Nous avons donc dû utiliser un convertisseur de l'interface 10Gi en deux interfaces Gi.
 +
Une fois cela effectué, nous pouvions relier la fibre au commutateur qui était lui-même relié au serveur Cordouan.
 +
Il fallait seulement changer le mode access du port sur le commutateur et le configurer en Trunk.
 +
 +
Une fois cela effectué et bien configuré, nous parvenons à "pinger" notre routeur depuis notre machine virtuelle.
 +
 +
<pre>
 +
# ping 193.48.57.172
 +
PING 193.48.57.172 (193.48.57.172) 56(84) bytes of data.
 +
64 bytes from 193.48.57.172: icmp_seq=1 ttl=255 time=6.23 ms
 +
64 bytes from 193.48.57.172: icmp_seq=2 ttl=255 time=1.01 ms
 +
64 bytes from 193.48.57.172: icmp_seq=3 ttl=255 time=19.8 ms
 +
64 bytes from 193.48.57.172: icmp_seq=4 ttl=255 time=1.56 ms
 +
64 bytes from 193.48.57.172: icmp_seq=5 ttl=255 time=8.55 ms
 +
64 bytes from 193.48.57.172: icmp_seq=6 ttl=255 time=2.36 ms
 +
^C
 +
--- 193.48.57.172 ping statistics ---
 +
2 packets transmitted, 2 received, 0% packet loss, time 5007ms
 +
rtt min/avg/max/mdev = 1.018/6.593/19.818/6.495 ms
 +
</pre>
 +
 +
===Réalisation 5ème semaine ===
 +
 +
=====Configuration machine virtuelle=====
 +
Installation des packages ssh, apache2 et bind9.
 +
 +
Modification du fichier :
 +
<pre>
 +
/etc/bind/db.hamtaro.space
 +
</pre>
 +
 +
<pre>
 +
;
 +
; BIND data file for local loopback interface
 +
;
 +
$TTL 604800
 +
@ IN SOA ns.hamtaro.space. root.hamtaro.space (
 +
      3 ; Serial
 +
604800 ; Refresh
 +
  86400 ; Retry
 +
2419200 ; Expire
 +
604800 ) ; Negative Cache TTL
 +
IN NS ns.hamtaro.space.
 +
IN NS ns6.gandi.net.
 +
IN MX 100 ns.hamtaro.space.
 +
 +
ns IN A 193.48.57.166
 +
www IN A 193.48.57.166
 +
 +
</pre>
 +
 +
Modification du fichier :
 +
<pre>
 +
/etc/bind/named.conf.local
 +
</pre>
 +
 +
<pre>
 +
//
 +
// Do any local configuration here
 +
//
 +
 +
// Consider adding the 1918 zones here, if they are not used in your
 +
// organization
 +
//include "/etc/bind/zones.rfc1918";
 +
zone "hamtaro.space" IN {
 +
                type master;
 +
                file "/etc/bind/db.hamtaro.space";
 +
                allow-transfer {217.70.177.40;};
 +
        };
 +
</pre>
 +
 +
On va ensuite sur le site de Gandi pour modifier des informations.
 +
Les Glue Records :
 +
<pre>
 +
'Nom du serveur' : ns.hamtaro.space
 +
'IP' : 193.48.57.166
 +
</pre>
 +
 +
Puis dans la rubrique modifier les serveurs DNS :
 +
<pre>
 +
'DNS1' : ns.hamtaro.space
 +
'DNS2' : ns6.gandi.net
 +
</pre>
 +
 +
Sécurisation de site web par certificat :
 +
 +
On tape la commande :
 +
<pre>
 +
openssl req -nodes -newkey rsa:2048 -sha256 -keyout hamtaro.space.key -out hamtaro.space.csr
 +
</pre>
 +
 +
Puis on remplis les champs demandés :
 +
<pre>
 +
Country Name (2 letter code) [AU]:FR
 +
State or Province Name (full name) [Some-State]:Nord
 +
Locality Name (eg, city) []:Lille
 +
Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille
 +
Organizational Unit Name (eg, section) []:
 +
Common Name (e.g. server FQDN or YOUR name) []:hamtaro.space
 +
</pre>
 +
 +
On se rend ensuite sur le site de Gandi et on rentre le contenu du fichier hamtaro.space.csr dans le champs CSR prévu à cet effet puis nous attendons la validation de notre certificat.
 +
 +
===== Configuration routeur=====
 +
Configuration IPV6 des Vlan:
 +
<pre>
 +
ipv6 enable       
 +
ipv6 address 2001:660:4401:60XX::/64 eui-64                                                                                             
 +
ipv6 nd prefix 2001:660:4401:60XX::/64 1000 900 
 +
</pre>
 +
 +
Avec les valeurs de XX variant de B0 à BA.
 +
Pour le vlan130, cette valeur change : AA.
 +
 +
Interconnexion IPV4:
 +
<pre>
 +
router ospf 1                                                                 
 +
router-id 10.60.2.2                                                                                                                   
 +
summary-address 10.60.0.0 255.255.0.0                                         
 +
summary-address 193.48.57.160 255.255.255.240                                 
 +
redistribute connected metric 30 subnets                                     
 +
network 192.168.222.0 0.0.0.7 area 1
 +
</pre>
 +
 +
Interconnexion IPV6:
 +
<pre>
 +
ipv6 router rip tpima5sc                                                       
 +
redistribute connected metric 1                                               
 +
redistribute static metric 1                                                 
 +
redistribute rip 1 metric 1
 +
</pre>
 +
 +
Une fois cela effectué, il faut que le vlan d'interconnexion prenne en compte ces modifications, il faut donc ajouter la commande :
 +
<pre>
 +
ipv6 rip tpima5sc enable
 +
</pre>
 +
Enfin, pour confirmer la configuration effectuée, nous affichons la table de routage ipv6 :
 +
  sh ipv6 route
 +
 +
On obtient alors le résultat suivant :
 +
<pre>
 +
IPv6 Routing Table - Default - 65 entries                                     
 +
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route         
 +
      B - BGP, R - RIP, D - EIGRP, EX - EIGRP external                       
 +
      O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2     
 +
      ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2                           
 +
R  ::/0 [120/2]                                                               
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
R  2001:660:4401:60::/64 [120/2]                                             
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
R  2001:660:4401:6000::/56 [120/2]                                           
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
R  2001:660:4401:6002::/64 [120/2]                                           
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
R  2001:660:4401:6003::/64 [120/2]                                           
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
R  2001:660:4401:6004::/64 [120/2]                                           
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
R  2001:660:4401:6005::/64 [120/2]                                           
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
R  2001:660:4401:6006::/64 [120/2]                                           
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
R  2001:660:4401:6007::/64 [120/2]                                           
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
R  2001:660:4401:6008::/64 [120/2]                                           
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
R  2001:660:4401:6009::/64 [120/2]                                           
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
R  2001:660:4401:6011::/64 [120/2]                                           
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
R  2001:660:4401:6013::/64 [120/2]                                           
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
R  2001:660:4401:6014::/64 [120/2]                                           
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
R  2001:660:4401:6015::/64 [120/2]                                           
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
R  2001:660:4401:6016::/64 [120/2]                                           
 +
    via FE80::211:5DFF:FEF2:5400, Vlan130                                     
 +
... 
 +
</pre>
 +
 +
On essaie ensuite de ping le site de google depuis la machine virtuelle. On obtient un résultat positif. Notre configuration est donc fonctionnelle.
 +
 +
===== Sécurisation du réseau par HSRP =====
 +
Pour empêcher les pertes de transmission de paquets, il faut ajouter une passerelle sur chaque interface.
 +
De plus il faut ajouter l'adresse du routeur virtuel sur le vlan des machines virtuelles à savoir : 193.48.57.173.
 +
On a alors :
 +
<pre>
 +
interface Vlan12
 +
ip address 193.48.57.172 255.255.255.240
 +
standby 1 ip 193.48.57.173
 +
standby 1 priority 110
 +
standby 1 preempt
 +
</pre>
 +
 +
Une fois cela effectué sur notre routeur mais aussi sur le routeur de Stéphane et Thomas (groupe 5), nous réussissons à pinger leurs interfaces virtuelles ainsi que les interfaces de la machine virtuelle.
 +
Nous pouvons également voir lors de l'affichage de la configuration en standby que notre routeur est considéré comme local tandis que le leur est en standby. La ligne traitant de la priorité fonctionne donc et permet la redondance du système.
 +
 +
===Réalisation 6ème semaine ===
 +
====Suite Sécurisation SSL====
 +
Après avoir obtenu notre certificat SSL sur le site GANDI, nous pouvons copier les fichiers utiles dans le dossier ssl:
 +
<pre>
 +
root@Kadoc:/etc/bind# cp certificat.crt /etc/ssl/certs/hamtaro.space.crt
 +
root@Kadoc:/etc/bind# cp hamtaro.space.key /etc/ssl/private/hamtaro.space.key
 +
root@Kadoc:/etc/bind# cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem
 +
</pre>
 +
 +
 +
Nous créons le fichier 000-hamtaro.space-ssl.conf dans le dossier "apache2/sites-available" afin de pouvoir joindre notre nom de serveur et Apache:
 +
<pre>
 +
#NameVirtualHost *:443
 +
        <VirtualHost 193.48.57.166:443>
 +
                ServerName www.hamtaro.space
 +
                ServerAlias hamtaro.space
 +
                DocumentRoot /var/www/www.hamtaro.space/
 +
                CustomLog /var/log/apache2/secure_acces.log combined
 +
 +
                SSLEngine on
 +
                SSLCertificateFile /etc/ssl/certs/hamtaro.space.crt
 +
                SSLCertificateKeyFile /etc/ssl/private/hamtaro.space.key
 +
                SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem
 +
                SSLVerifyClient None
 +
        </VirtualHost>
 +
        <Directory /var/www/www.hamtaro.space>
 +
                Require all granted
 +
        </Directory>
 +
ServerName "hamtaro.space"
 +
</pre>
 +
 +
Enfin, nous devons modifier le fichier ports.conf afin que le serveur Apache écoute sur le port 443.
 +
<pre>
 +
Listen 80 443
 +
 +
<IfModule ssl_module>
 +
        Listen 443
 +
</IfModule>
 +
 +
#<IfModule mod_gnutls.c>
 +
#      Listen 443
 +
#</IfModule>
 +
 +
#<IfModule mod_ssl.c>
 +
#      Listen 443
 +
        #NameVirtualHost *:443
 +
#</IfModule>
 +
</pre>
 +
 +
Nous pouvons désormais activer le module SSL de apache :
 +
<pre>a2enmod ssl</pre>
 +
 +
Puis nous pouvons activer notre certificat pour notre site :
 +
<pre>
 +
a2ensite 000-hamtaro.space-ssl.conf
 +
Enabling site 000-hamtaro.space-ssl.
 +
service apache2 reload                //afin de charger la nouvelle configuration.
 +
</pre>
 +
 +
Nous pouvons donc maintenant voir que notre site est sécurisé en allant sur https://www.hamtaro.space <br />
 +
Il y a en effet le cadenas vert symbolisant cela:
 +
 +
[[Fichier:Screensecuresite.png]]
 +
 +
====Sécurisation par DNSSEC====
 +
 +
Dans un premier temps on va modifier le fichier /etc/bind/named.conf.options et rajouter la ligne :
 +
<pre>
 +
dnssec-enable yes
 +
</pre>
 +
 +
Nous devons maintenant générer les clés (fichiers KSK et ZSK) que nous utiliserons afin de signer les zones:
 +
<pre>
 +
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE hamtaro.space
 +
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hamtaro.space
 +
</pre>
 +
 +
Nous les plaçons dans un dossier nommé hamtaro.space.dnssec.
 +
 +
Nous modifions ensuite le fichier db.hamtaro.space afin d'inclure ces deux clés:
 +
<pre>
 +
$include /etc/bind/hamtaro.space.dnssec/hamtaro.space-ksk.key
 +
$include /etc/bind/hamtaro.space.dnssec/hamtaro.space-zsk.key
 +
</pre>
 +
 +
Il nous faut maintenant signer la zone :
 +
<pre> dnssec-signzone -o hamtaro.space -k hamtaro.space-ksk ../db.hamtaro.space hamtaro.space-zsk
 +
Verifying the zone using the following algorithms: RSASHA1.
 +
Zone fully signed:
 +
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
 +
                    ZSKs: 1 active, 0 stand-by, 0 revoked
 +
../db.hamtaro.space.signed
 +
</pre>
 +
 +
Nous ajoutons ensuite le DNSSEC sur Gandi :
 +
[[Fichier:dnssecKadoc.png]]
 +
 +
On peut ensuite vérifier que notre DNSSEC est bien sécurisé :
 +
<pre>
 +
root@Kadoc:/etc/bind# dig DNSKEY hamtaro.space @localhost
 +
 +
; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> DNSKEY hamtaro.space @localhost
 +
;; global options: +cmd
 +
;; Got answer:
 +
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5615
 +
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
 +
 +
;; OPT PSEUDOSECTION:
 +
; EDNS: version: 0, flags:; udp: 4096
 +
;; QUESTION SECTION:
 +
;hamtaro.space. IN DNSKEY
 +
 +
;; AUTHORITY SECTION:
 +
hamtaro.space. 604800 IN SOA ns.hamtaro.space. root.hamtaro.space.hamtaro.space. 3 604800 86400 2419200 604800
 +
 +
;; Query time: 0 msec
 +
;; SERVER: 127.0.0.1#53(127.0.0.1)
 +
;; WHEN: Mon Nov 28 13:21:10 CET 2016
 +
;; MSG SIZE  rcvd: 100
 +
 +
</pre>
 +
 +
====Partition RAID5====
 +
Pour assurer la sécurisation des données, nous configurons trois partitions de volumes logiques sur la machine virtuelle:
 +
 +
<pre>
 +
lvcreate -L 1G -n /dev/virtual/ima5-lapoulette
 +
lvcreate -L 1G -n /dev/virtual/ima5-Karadoc
 +
lvcreate -L 1G -n /dev/virtual/ima5-pelinord
 +
</pre>
 +
 +
Puis nous modifions le fichier de configuration de notre machine virtuelle :
 +
<pre>
 +
disk        = [
 +
                  'file:/usr/local/xen/domains/Kadoc/disk.img,xvda2,w',
 +
                  'file:/usr/local/xen/domains/Kadoc/swap.img,xvda1,w',
 +
  'phy:/dev/virtual/ima5-pelinord,xvdb,w',
 +
                  'phy:/dev/virtual/ima5-Karadoc,xvdc,w',
 +
                  'phy:/dev/virtual/ima5-lapoulette,xvdd,w', 
 +
      ]
 +
</pre>
 +
 +
Nous pouvons maintenant relancer notre machine virtuelle.
 +
Nous pouvons y créer le RAID5 avec les 3 partitions:
 +
<pre> mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdb /dev/xvdc /dev/xvdd </pre>
 +
 +
On peut ensuite voir le détail de la configuration :
 +
<pre>
 +
root@Kadoc:~# mdadm --detail /dev/md0
 +
/dev/md0:
 +
        Version : 1.2
 +
  Creation Time : Tue Nov 29 13:06:20 2016
 +
    Raid Level : raid5
 +
    Array Size : 2095104 (2046.34 MiB 2145.39 MB)
 +
  Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
 +
root@Kadoc:~# mdadm --detail /dev/md0
 +
/dev/md0:
 +
        Version : 1.2
 +
  Creation Time : Tue Nov 29 12:06:20 2016
 +
    Raid Level : raid5
 +
    Array Size : 2095104 (2046.34 MiB 2145.39 MB)
 +
  Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
 +
  Raid Devices : 3
 +
  Total Devices : 3
 +
    Persistence : Superblock is persistent
 +
 +
    Update Time : Tue Nov 29 13:18:04 2016
 +
          State : clean
 +
Active Devices : 3
 +
Working Devices : 3
 +
Failed Devices : 0
 +
  Spare Devices : 0
 +
 +
        Layout : left-symmetric
 +
    Chunk Size : 512K
 +
 +
          Name : Kadoc:0  (local to host Kadoc)
 +
          UUID : 90156134:39a740fa:0de8c29d:486dce2c
 +
        Events : 22
 +
 +
    Number  Major  Minor  RaidDevice State
 +
      0    202      16        0      active sync  /dev/xvdb
 +
      1    202      32        1      active sync  /dev/xvdc
 +
      3    202      48        2      active sync  /dev/xvdd
 +
</pre>
 +
 +
Nous devons ensuite sauvegarder cette configuration afin de garder notre md0, pour cela:
 +
<pre> mdadm --detail --scan >> /etc/mdadm/mdadm.conf </pre>
 +
puis nous pouvons copier les données sur le RAID5:
 +
<pre>
 +
root@Kadoc:~# mkfs /dev/md0
 +
mke2fs 1.42.12 (29-Aug-2014)
 +
Creating filesystem with 523776 4k blocks and 131072 inodes
 +
Filesystem UUID: 2703e116-ed2c-46fe-964a-928be0b34cd6
 +
Superblock backups stored on blocks:
 +
32768, 98304, 163840, 229376, 294912
 +
 +
Allocating group tables: done                           
 +
Writing inode tables: done                           
 +
Writing superblocks and filesystem accounting information: done
 +
</pre>
 +
Puis:
 +
<pre>
 +
root@Kadoc:~# mount /dev/md0 /mnt
 +
[  702.230079] EXT4-fs (md0): mounting ext2 file system using the ext4 subsystem
 +
[  702.309734] EXT4-fs (md0): mounted filesystem without journal. Opts: (null)
 +
</pre>
 +
 +
Nous allons maintenant voir ce qu'il se passe lorsque l'on enlève une des partitions à la machine.
 +
Nous redémarrons la machine virtuelle et nous affichons le détail :
 +
<pre>
 +
root@Kadoc:~# mdadm --detail /dev/md0
 +
/dev/md0:
 +
        Version : 1.2
 +
  Creation Time : Tue Nov 29 12:23:50 2016
 +
    Raid Level : raid5
 +
    Array Size : 2095104 (2046.34 MiB 2145.39 MB)
 +
  Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
 +
  Raid Devices : 3
 +
  Total Devices : 2
 +
    Persistence : Superblock is persistent
 +
 +
    Update Time : Tue Nov 29 12:43:56 2016
 +
          State : clean, degraded
 +
Active Devices : 2
 +
Working Devices : 2
 +
Failed Devices : 0
 +
  Spare Devices : 0
 +
 +
        Layout : left-symmetric
 +
    Chunk Size : 512K
 +
 +
          Name : Kadoc:0  (local to host Kadoc)
 +
          UUID : b333670e:27b24fbe:045a7e98:c7eafb49
 +
        Events : 14
 +
 +
    Number  Major  Minor  RaidDevice State
 +
      0    202      16        0      active sync  /dev/xvdb
 +
      2      0        0        2      removed
 +
      2    202      48        2      active sync  /dev/xvdd
 +
</pre>
 +
 +
Nous voyons donc bien qu'une partition a été enlevée.
 +
Pour réparer cela,
 +
<pre>
 +
mdadm --set-faulty /dev/md0 /dev/xvdc
 +
mdadm --remove /dev/md0 /dev/xvdc
 +
</pre>
 +
 +
La partition est bien supprimée:
 +
<pre>
 +
Personalities : [raid6] [raid5] [raid4]
 +
md0 : active raid5 xvdb[0] xvdd[3]
 +
      2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
 +
</pre>
 +
 +
On remet la partition:
 +
<pre>mdadm --add /dev/md0 /dev/xvdc</pre>
 +
 +
On peut ensuite suivre l'avancement de la restauration:
 +
<pre>
 +
root@Kadoc:/dev# cat /proc/mdstat
 +
Personalities : [raid6] [raid5] [raid4]
 +
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
 +
      2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
 +
      [===========>.........]  recovery = 56.9% (596964/1047552) finish=0.2min speed=29848K/sec
 +
       
 +
unused devices: <none>
 +
root@Kadoc:/dev# cat /proc/mdstat
 +
Personalities : [raid6] [raid5] [raid4]
 +
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
 +
      2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
 +
      [=============>.......]  recovery = 66.9% (701992/1047552) finish=0.1min speed=29249K/sec
 +
     
 +
unused devices: <none>
 +
root@Kadoc:/dev# cat /proc/mdstat
 +
Personalities : [raid6] [raid5] [raid4]
 +
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
 +
      2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
 +
      [===============>.....]  recovery = 75.0% (786728/1047552) finish=0.1min speed=29138K/sec
 +
     
 +
unused devices: <none>
 +
root@Kadoc:/dev# cat /proc/mdstat
 +
Personalities : [raid6] [raid5] [raid4]
 +
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
 +
      2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
 +
      [=================>...]  recovery = 85.1% (892660/1047552) finish=0.0min speed=29755K/sec
 +
 +
unused devices: <none>
 +
root@Kadoc:/dev# cat /proc/mdstat
 +
Personalities : [raid6] [raid5] [raid4]
 +
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
 +
      2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
 +
      [===================>.]  recovery = 99.6% (1044732/1047552) finish=0.0min speed=30465K/sec
 +
     
 +
unused devices: <none>
 +
root@Kadoc:/dev# [  156.292138] md: md0: recovery done.
 +
cat /proc/mdstat
 +
Personalities : [raid6] [raid5] [raid4]
 +
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
 +
      2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
 +
     
 +
unused devices: <none>
 +
</pre>
 +
 +
Enfin, on retrouve la configuration initiale :
 +
<pre>
 +
root@Kadoc:~# mdadm --detail /dev/md0
 +
/dev/md0:
 +
        Version : 1.2
 +
  Creation Time : Tue Nov 29 13:06:20 2016
 +
    Raid Level : raid5
 +
    Array Size : 2095104 (2046.34 MiB 2145.39 MB)
 +
  Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
 +
root@Kadoc:~# mdadm --detail /dev/md0
 +
/dev/md0:
 +
        Version : 1.2
 +
  Creation Time : Tue Nov 29 13:06:20 2016
 +
    Raid Level : raid5
 +
    Array Size : 2095104 (2046.34 MiB 2145.39 MB)
 +
  Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
 +
  Raid Devices : 3
 +
  Total Devices : 3
 +
    Persistence : Superblock is persistent
 +
 +
    Update Time : Tue Nov 29 13:18:04 2016
 +
          State : clean
 +
Active Devices : 3
 +
Working Devices : 3
 +
Failed Devices : 0
 +
  Spare Devices : 0
 +
 +
        Layout : left-symmetric
 +
    Chunk Size : 512K
 +
 +
          Name : Kadoc:0  (local to host Kadoc)
 +
          UUID : 90156134:39a740fa:0de8c29d:486dce2c
 +
        Events : 22
 +
 +
    Number  Major  Minor  RaidDevice State
 +
      0    202      16        0      active sync  /dev/xvdb
 +
      1    202      32        1      active sync  /dev/xvdc
 +
      3    202      48        2      active sync  /dev/xvdd
 +
</pre>
 +
 +
==== Cryptage de données ====
 +
 +
Pour cette partie, nous commençons par installer lvm2, Gparted ainsi que cryptsetup sur notre eeePc.
 +
Nous voulons une seule partition sur la carte SD. Pour cela on utilise:
 +
<pre>
 +
fdisk /dev/mmcblk1
 +
</pre>
 +
On créé alors une partition primaire sur tout l'espace disponible de la carte.
 +
 +
Une fois cette partition créée, elle n'est pas cryptée, nous allons donc maintenant utiliser le cryptsetup:
 +
 +
<pre>
 +
cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk1
 +
</pre>
 +
Cette commande permet de formatter la partition au type Luks avec un chiffrement AES avec un algorithme de hâchage SHA256.
 +
On doit aussi choisir un mot de passe pour crypter la partition.
 +
 +
Pour voir l'état du conteneur, on peut utiliser la commande :
 +
<pre>
 +
root@lamproie:~# cryptsetup luksDump /dev/mmcblk1
 +
LUKS header information for /dev/mmcblk1
 +
 +
Version:      1
 +
Cipher name:  aes
 +
Cipher mode:  cbc-plain
 +
Hash spec:    sha256
 +
Payload offset: 4096
 +
MK bits:      256
 +
MK digest:    b9 ed bc f9 68 3c ac 64 d4 3b a4 44 5b 48 38 b2 d1 b4 7d 87
 +
MK salt:      8a a5 f6 38 a7 08 fe 6b 90 7d 88 79 10 fc 70 15
 +
              95 e0 67 82 ee 34 fe 87 23 3e 2a 77 f7 ed cf 35
 +
MK iterations: 125750
 +
UUID:          07082d69-6117-42f8-81a3-695d1ea8e5df
 +
 +
Key Slot 0: ENABLED
 +
Iterations:        1007873
 +
Salt:              98 b5 bd 00 ca 5b 70 81 62 50 8d 5f ba ea d9 4c
 +
                      35 38 70 bf 09 0b da 95 51 cb 81 c0 35 2d fe da
 +
Key material offset: 8
 +
AF stripes:            4000
 +
Key Slot 1: DISABLED
 +
Key Slot 2: DISABLED
 +
Key Slot 3: DISABLED
 +
Key Slot 4: DISABLED
 +
Key Slot 5: DISABLED
 +
Key Slot 6: DISABLED
 +
Key Slot 7: DISABLED
 +
</pre>
 +
 +
On ouvre ensuite notre partition cryptée:
 +
<pre> cryptsetup luksOpen /dev/mmcblk1 kadoc </pre>
 +
 +
On peut ainsi ajouter le système de fichiers à notre partition cryptée:
 +
<pre>mkfs.ext3 /dev/mapper/kadoc</pre>
 +
 +
Ensuite, nous pouvons monter la partition pour pouvoir y écrire. Nous pouvons aussi la démonter lorsque nos fichiers seront copiés:
 +
<pre>
 +
mount -t ext3 /dev/mapper/kadoc /mnt/        //pour monter la partition.
 +
 +
umount /mnt/                                  //pour démonter la partition.
 +
</pre>
 +
 +
Enfin pour encrypter à nouveau cette partition, on utilise la commande:
 +
<pre> cryptsetup luksClose kadoc </pre>
 +
 +
On utilise la commande <pre> gparted /dev/mmcblk1 </pre> afin de voir la partition, on obtient ceci:
 +
 +
[[Fichier:Screencrypt.png]]
 +
 +
On voit donc que les informations de cette partition ne sont pas disponibles à moins d'avoir la clé.
 +
 +
===Réalisation 7ème semaine ===
 +
Lors de cette semaine nous avons pu connecter le points d'accès Wifi de Valentin et Alexandre sur le commutateur de la salle E304. Pour cela, nous avons dû configurer un vlan1 sur le routeur qui prend l'adresse 10.60.1.3.
 +
Ainsi, nous avons pu nous trouver ce point d'accès qui a pris l'adresse 10.60.1.6.
 +
Nous avions ainsi les deux points d'accès qui étaient connectés dans chaque salle :
 +
En E304 : avec l'adresse 10.60.1.6 et en E306 : 10.60.1.2.
 +
 +
Une fois cela fait, nous pouvons passer à la sécurisation Wifi par WPA2-EAP.
 +
 +
=====Sécurisation Wifi par WPA2-EAP=====
 +
Nous allons utiliser cette méthode afin de créer le point d'accès que nous avons mentionné plus haut et d'en sécuriser la connexion.
 +
Tout d'abord, nous devons créer le serveur FreeRadius:
 +
Nous devons tout d'abord modifier certains fichiers de configuration du serveur :
 +
dans le fichier ''eap.conf'' nous devons modifier une ligne afin de modifier le protocole d'identification :
 +
<pre> default_eap_type = peap </pre>
 +
 +
Une fois cela fait, nous devons modifier le fichier ''clients.conf'', ce qui nous permettra de configurer nos points d'accès Wifi:
 +
<pre>
 +
 +
client E304 {
 +
ipaddr          = 10.60.1.6
 +
secret = kadoc
 +
shortname = wifi1
 +
}
 +
 +
client E306 {
 +
ipaddr = 10.60.1.2
 +
secret = kadoc
 +
shortname = wifi2
 +
}
 +
</pre>
 +
Nous avons ainsi configuré les deux points d'accès.
 +
 +
Enfin, nous devons ajouter une ligne au fichier users qui va nous permettre de créer un nouvel utilisateur pour l'identification:
 +
<pre> karadoc Cleartext-Password := "perceval" </pre>
 +
 +
Une fois cela fait, nous pouvons lancer notre serveur FreeRadius.
 +
 +
Nous allons maintenant passer à la configuration du point d'accès afin d'avoir un accès sécurisé avec notre serveur précédemment détaillé:
 +
<pre>
 +
telnet 10.60.1.6
 +
 +
...
 +
 +
conf t
 +
 +
aaa new-model
 +
aaa authentication login eap_kadoc group radius_kadoc
 +
radius-server host 193.48.57.166 auth-port 1812 acct-port 1813 key kadoc
 +
aaa group server radius radius_kadoc
 +
server 193.48.57.166 auth-port 1812 acct-port 1813
 +
 +
exit
 +
 +
dot11 ssid SSID_KADOC
 +
vlan 7
 +
authentication open eap eap_kadoc
 +
authentication network-eap eap_kadoc
 +
authentication key-management wpa
 +
mbssid guest-mode
 +
 +
exit
 +
 +
interface Dot11Radio0
 +
encryption vlan 7 mode ciphers aes-ccm tkip
 +
ssid SSID_KADOC
 +
 +
exit
 +
 +
interface Dot11Radio0.7
 +
encapsulation dot1Q 7
 +
no ip route-cache
 +
bridge-group 7
 +
bridge-group 7 subscriber-loop-control
 +
bridge-group 7 spanning-disabled
 +
bridge-group 7 block-unknown-source
 +
no bridge-group 7 source-learning
 +
no bridge-group 7 unicast-flooding
 +
 +
exit
 +
 +
interface GigabitEthernet0.7
 +
encapsulation dot1Q 7
 +
bridge-group 7
 +
 +
exit
 +
 +
exit
 +
 +
write
 +
</pre>
 +
 +
La borne est maintenant configurée, il ne nous reste plus qu'à nous y connecter.
 +
 +
Pour cela, nous devons encore modifier le wlan0 de l'eeepc.
 +
Nous modifions donc le fichier /etc/network/interfaces :
 +
<pre>
 +
auto wlan0
 +
iface wlan0 inet static
 +
  address 10.60.7.7
 +
  netmask 255.255.255.0
 +
  gateway 10.60.7.1
 +
  wpa-ssid KADOC
 +
  wpa-key-mgmt WPA-EAP
 +
  wpa-identity karadoc
 +
  wpa-password perceval
 +
</pre>
 +
 +
Une fois cela fait, nous pouvons nous connecter sur le point d'accès de la salle E304. Pour se connecter sur celui de la E306, il faudrait faire la même configuration sur ce point d'accès.
 +
Nous avons réussi à nous connecter à ce point d'accès en rentrant une adresse IP valide à la main. Pour rendre cela automatique, nous devrons installer un serveur DHCP sur notre Eeepc qui nous permettre d'attribuer une adresse IP à notre smartphone
 +
Une fois notre serveur DHCP installé et correctement configuré, nous pouvons nous connecter comme prévu sans avoir à rentrer une adresse IP "à la main".
 +
 +
[[Fichier:KadocConnected.png||200px||center]]
 +
 +
===Réalisation 9ème semaine ===
 +
 +
Nous avons dans un premier temps installer Asterisk
 +
<pre>
 +
apt-get install asterisk
 +
</pre>
 +
 +
Nous avons ensuite configuré le fichier <pre> /etc/asterisk/users.conf </pre> en y ajoutant :
 +
<pre>
 +
[general]
 +
  hasvoicemail = yes
 +
  hassip = yes
 +
  hasiax = yes
 +
  callwaiting = yes
 +
  threewaycalling = yes
 +
  callwaitingcallerid = yes
 +
  transfer = yes
 +
  canpark = yes
 +
  cancallforward = yes
 +
  callreturn = yes
 +
  callgroup = 1
 +
  pickupgroup = 1
 +
  nat = yes
 +
 +
  [6001]
 +
  type=peer
 +
  host=dynamic
 +
  dtmfmode=rfc2833
 +
  disallow=all
 +
  allow=ulaw
 +
  fullname = kadoc
 +
  username = heykadoc
 +
  secret = perceval
 +
  context = work
 +
 +
  [6002]
 +
  type=peer
 +
  host=dynamic
 +
  dtmfmode=rfc2833
 +
  disallow=all
 +
  allow=ulaw
 +
  fullname = karadoc
 +
  username = heykaradoc
 +
  secret = perceval
 +
  context = work
 +
</pre>
 +
 +
Ensuite, on ajoute dans le fichier <pre>/etc/asterisk/extensions.conf :</pre>
 +
<pre>
 +
  [work]
 +
  exten => _6XXX,1,Dial(SIP/${EXTEN},20)
 +
  exten => _6XXX,2,Hangup()
 +
</pre>
 +
 +
On restart ensuite asterisk :
 +
<pre>
 +
service asterisk restart
 +
</pre>
 +
 +
Puis on reload l'ensemble des fichiers afin qu'ils soient pris en compte :
 +
<pre>
 +
reload
 +
</pre>
 +
 +
 +
On cherche maintenant à savoir si notre configuration fonctionne. Pour cela, nous installons l'application CSipSimple sur deux téléphones Android sur lesquels nous configurons deux comptes.
 +
 +
Lorsque nous essayons de nous appeler, nous voyons que la communication fonctionne:
 +
[[Fichier:15497641_10210148661905836_1314328693_n.jpg||400px||center]]

Version actuelle datée du 6 janvier 2017 à 11:12

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:

Travail.jpeg

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:

Screensecuresite.png

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 : DnssecKadoc.png

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 kadoc
On utilise la commande 
 gparted /dev/mmcblk1
afin de voir la partition, on obtient ceci:

Screencrypt.png

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

Réalisation 7ème semaine

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

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

Sécurisation Wifi par WPA2-EAP

Nous allons utiliser cette méthode afin de créer le point d'accès que nous avons mentionné plus haut et d'en sécuriser la connexion. Tout d'abord, nous devons créer le serveur FreeRadius: Nous devons tout d'abord modifier certains fichiers de configuration du serveur : dans le fichier eap.conf nous devons modifier une ligne afin de modifier le protocole d'identification : 

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

KadocConnected.png

Réalisation 9ème semaine

Nous avons dans un premier temps installer Asterisk 

apt-get install asterisk
Nous avons ensuite configuré le fichier 
 /etc/asterisk/users.conf
en 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 = work
Ensuite, 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:

15497641 10210148661905836 1314328693 n.jpg
Récupérée de « https://wiki-ima.plil.fr/mediawiki//index.php?title=Cahier_2016_groupe_n°6&oldid=36988 »