TP sysres IMA2a5 2017/2018 G1 : Différence entre versions
(Page créée avec « == Machine virtuelle == Lors de notre première séance nous avons créé une machine virtuelle Xen Linux sur le dom0 cordouan.insecserv.deule.net Le nom de notre machine vi... ») |
(→Machine virtuelle) |
||
(30 révisions intermédiaires par 2 utilisateurs non affichées) | |||
Ligne 2 : | Ligne 2 : | ||
Lors de notre première séance nous avons créé une machine virtuelle Xen Linux sur le dom0 cordouan.insecserv.deule.net | Lors de notre première séance nous avons créé une machine virtuelle Xen Linux sur le dom0 cordouan.insecserv.deule.net | ||
− | Le nom de notre machine virtuelle est RinceCochon. | + | Le nom de notre machine virtuelle est RinceCochon et a comme adresse ip 193.48.57.168. |
− | On lui a ensuite alloué un espace disque plus important, 10G pour son / | + | On lui a ensuite alloué un espace disque plus important, 10G pour son /var et 10G pour son /home. |
+ | On crée 2 dossier de 10G sur cordouan | ||
+ | lvcreate -L10G -nIMA2A5_rincecochon_var virtual | ||
+ | lvcreate -L10G -nIMA2A5_rincecochon_home virtual | ||
+ | mke2fs /dev/virtual/IMA2A5_rincecochon_var | ||
+ | mke2fs /dev/virtual/IMA2A5_rincecochon_home | ||
− | + | On rajoute ensuite les nouveaux disque dans rincecochon.cfg | |
+ | phy:/dev/virtual/IMA2A5_rincecochon_home, xvdb1,w | ||
+ | phy:/dev/virtual/IMA2A5_rincecochon_var, xvdb2,w | ||
− | Dans un premier temps nous avons | + | Dans la machine virtuelle on monte les nouveaux disques à la place du dossier var et home déjà présent en fessant attention à ne pas faire une mauvaise manip se qui aurait pour terrible conséquence de tous casser. Et de nous faire recommencer à 0. |
+ | |||
+ | == Borne Cisco WEP == | ||
+ | |||
+ | Dans un premier temps nous avons configuré l'adresse IP de la borne WIFI | ||
+ | |||
+ | configure terminal | ||
+ | interface BVI 1 | ||
+ | ip address 10.100.0.4 255.255.255.0 | ||
+ | ip default-gateway 10.100.0.254 | ||
+ | no shutdown | ||
+ | end | ||
+ | |||
+ | Ainsi que le pont qui va nous permettre de relier les différents VLAN | ||
+ | |||
+ | configure terminal | ||
+ | bridge irb | ||
+ | bridge 1 route ip | ||
+ | end | ||
+ | |||
+ | Dans un second temps nous avons configuré les différents ssid et associé à leur VLAN (2 à 6) | ||
− | |||
configure terminal | configure terminal | ||
− | dot11 ssid | + | dot11 vlan-name BORNE_TESTX vlan X |
+ | dot11 ssid BORNE_TESTX | ||
+ | vlan X | ||
+ | authentication open | ||
+ | guest-mode | ||
exit | exit | ||
interface dot11Radio 0 | interface dot11Radio 0 | ||
− | ssid | + | no shutdown |
+ | ssid BORNE_TESTX | ||
Ensuite nous avons spécifié une clé de 128 bits pour chaque VLAN qui sont au nombre de 6. | Ensuite nous avons spécifié une clé de 128 bits pour chaque VLAN qui sont au nombre de 6. | ||
+ | |||
+ | interface Dot11Radio0 | ||
+ | mbssid | ||
+ | encryption vlan X mode wep mandatory | ||
+ | encryption vlan X key 1 size 128 #clé# transmit_key | ||
+ | |||
+ | On associe les différents vlan sur leurs bridge respectifs. | ||
+ | interface Dot11Radio0.X | ||
+ | encapsulation dot1Q X | ||
+ | bridge-group X | ||
+ | no shutdown | ||
+ | exit | ||
+ | |||
+ | Enfin on configure l'interface GigabitEthernet | ||
+ | |||
+ | interface GigabitEthernet0 | ||
+ | bridge-group 1 | ||
+ | no shutdown | ||
+ | exit | ||
+ | |||
+ | Et on associe les différents pont avec le réseau ethernet | ||
+ | |||
+ | interface GigabitEthernet0.X | ||
+ | encapsulation dot1Q X | ||
+ | bridge-group X | ||
+ | no shutdown | ||
+ | exit | ||
+ | |||
+ | == Borne Cisco WPA-PSK == | ||
+ | |||
+ | On a suivi le modéle précédent pour la configuration générale de la borne. Mais nous avons dû intégrer l'encryption WPA | ||
+ | |||
+ | configure terminal | ||
+ | dot11 ssid RinceCochon | ||
+ | vlan X | ||
+ | authentication open | ||
+ | authentication key-management wpa | ||
+ | wpa-psk ascii 0 mdp | ||
+ | mbssid guest-mode | ||
+ | exit | ||
+ | |||
+ | interface dot11Radio 0 | ||
+ | mbssid | ||
+ | encryption vlan 2 mode cipher tkip | ||
+ | ssid RinceCochon | ||
+ | |||
+ | L'action est réitéré pour chaque groupe | ||
+ | |||
+ | == Configuration d'une Zabeth pour le craquage clé WEP == | ||
+ | |||
+ | On vérifie dans un premier temps que l'ordinateur reconnaît la clé: | ||
+ | lsusb | ||
+ | Bus 004 Device 017: ID 0846:4240 NetGear, Inc. WG111(v1) rev 2 54 Mbps Wireless [Intersil ISL3887] | ||
+ | |||
+ | grâce aux commandes | ||
+ | ip a | ||
+ | iwconfig | ||
+ | |||
+ | La commande suivante permet de reboot le wifi: | ||
+ | /etc/init.d/networking restart | ||
+ | |||
+ | on retrouve les informations liés au réseau WIFI | ||
+ | |||
+ | Ensuite il faut modifier le fichier /etc/network/interfaces | ||
+ | |||
+ | auto wlx000fb5922451 | ||
+ | iface wlx000fb5922451 inet static | ||
+ | wireless-keymode open | ||
+ | wireless-mode managed | ||
+ | address 10.100.1.10 | ||
+ | netmask 255.255.255.0 | ||
+ | gateway 10.100.1.1 | ||
+ | wireless-essid BORNE_TESTX | ||
+ | wireless-key cléWEP | ||
+ | |||
+ | Téléchargement de arping | ||
+ | apt-get install arping | ||
+ | |||
+ | Envoie de paquets arp avec la borne | ||
+ | arping -W 0.01 10.200.1.1 | ||
+ | |||
+ | == Craquage clé WEP par force brute == | ||
+ | |||
+ | Dans un premier temps nous téléchargeons le package qui va vous permettre le craquage de la clé WEP | ||
+ | apt-get install aircrack-ng | ||
+ | |||
+ | Nous scanons ensuite les échanges des bornes wifi aux alentours pour détecter les bornes utilisant une clé WEP | ||
+ | airodump-ng --encrypt wep wlan0 | ||
+ | |||
+ | Grâce à cette commande nous récupérons le bssid de la borne visée ainsi que son canal de diffusion. | ||
+ | Ensuite nous lançons la commande qui va nous permettre d'écouter les échanges de la borne wifi | ||
+ | airodump-ng -w out -c 11 --bssid XX:XX:XX:XX:XX:XX wlan0 | ||
+ | Cette commande crée des fichiers contenant les échanges de la borne. Ce fichier va être utilisé pour le craquage force brut de la borne. | ||
+ | aircrack-ng out-01.cap | ||
+ | |||
+ | Après quelques minutes nous obtenons la clé WEP de la borne visée, nous permettant ainsi de nous connecter dessus sans problème. | ||
+ | |||
+ | == Serveur DNS == | ||
+ | |||
+ | Sur le site de gandi nous avons choisi le nom de domaine rincecochon.space. Après configuration nous avons comme serveur DNS primaire : dns.rincecochon.space => 193.48.57.168 | ||
+ | |||
+ | Comme tout nom de domaine doit être géré par au moins deux serveurs DNS distincts, pour assurer son bon fonctionnement au cas où l'un des deux serait en panne. Nous avons comme serveur secondaire le dns de gandi : ns6.gandi.net => 217.70.177.40 | ||
+ | |||
+ | Afin de configurer le serveur DNS sur la VM nous utilisons la package : bind9. | ||
+ | |||
+ | On configure maintenant le fichier named.conf.option | ||
+ | |||
+ | options { | ||
+ | directory "/var/cache/bind"; | ||
+ | dnssec-validation auto; | ||
+ | auth-nxdomain no; # conform to RFC1035 | ||
+ | listen-on-v6 { any; }; | ||
+ | allow-transfer { "allowed_to_transfer"; }; | ||
+ | }; | ||
+ | acl "allowed_to_transfer" { | ||
+ | 217.70.177.40/32; //cette ligne permettra d'autoriser le transfert de zone vers le serveur DNS secondaire “NS6.GANDI.NET” | ||
+ | }; | ||
+ | |||
+ | Après on modifie named.conf.local afin d'ajouter la “zone” pour notre domaine qui sera lié au serveur DNS | ||
+ | |||
+ | zone "rincecochon.space" { | ||
+ | type master; | ||
+ | file "/etc/bind/rincecochon.space"; | ||
+ | }; | ||
+ | |||
+ | On crée maintenant le fichier rincecochon.space qui sera notre fichier de zone | ||
+ | |||
+ | $TTL 259200 | ||
+ | @ IN SOA dns.rincecochon.space. postmaster.dns.rincecochon.space. ( | ||
+ | 2017100901 ; Version | ||
+ | 7200 ; Refresh (2h) | ||
+ | 3600 ; Retry (1h) | ||
+ | 1209600 ; Expire (14j) | ||
+ | 259200 ) ; Minimum TTL (3j) | ||
+ | IN NS dns.rincecochon.space. | ||
+ | IN NS ns6.gandi.net. | ||
+ | IN MX 100 dns.rincecochon.space. | ||
+ | IN A 193.48.57.168 | ||
+ | dns IN A 193.48.57.168 | ||
+ | |||
+ | Après modification de ce fichier, il faut incrémenter le numéro de version pour que la nouvelle version soit bien prise en compte au redémarrage du service bind. | ||
+ | Après que notre serveur DNS est opérationnel, nous avons fait la demande de certificat SSL. | ||
+ | |||
+ | |||
+ | == Sécurisation de site web par certificat == | ||
+ | |||
+ | Après avoir fait la création de notre clé privé et public, on ajoute ensuite la clé publique sur gandi pour qu'il génère 2 certificats. | ||
+ | |||
+ | -CerIntermediaire.crt qui contient le certificat intermédiaire. | ||
+ | |||
+ | -gandi.crt qui contient le certificat. | ||
+ | |||
+ | Dans le fichier /etc/apache2/sites-available/default-ssl.conf on modifie afin de passer en https : | ||
+ | |||
+ | <VirtualHost *:443> | ||
+ | ServerName www.rincecochon.space | ||
+ | ServerAlias rincecochon.space | ||
+ | DocumentRoot /var/www/html | ||
+ | SSLEngine on | ||
+ | SSLCertificateFile /etc/gandi.crt | ||
+ | SSLCertificateKeyFile /etc/monserveur.key | ||
+ | SSLCertificateChainFile /etc/CerIntermediaire.crt | ||
+ | </VirtualHost> | ||
+ | |||
+ | On utilise ensuite la commande : a2ensite default-ssl.conf afin d'activé la nouvelle configuration sur le site. | ||
+ | |||
+ | == Sécurisation de serveur DNS par DNSSEC == | ||
+ | |||
+ | On génère ensuite la clef asymétrique de signature de clefs de zone dans le nouveau répertoire rincecochon.space.dnssec | ||
+ | dnssec-keygen -r /dev/urandom -a RSASHA1 -b 2048 -f KSK -n ZONE rincecochon.space | ||
+ | |||
+ | Ainsi que la clef asymétrique de la zone pour signer les enregistrements | ||
+ | dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n ZONE rincecochon.space | ||
+ | |||
+ | On renomme les deux paires de clefs obtenues par | ||
+ | rincecochon.space-ksk.key | ||
+ | rincecochon.space-zsk.key | ||
+ | rincecochon.space-ksk.private | ||
+ | rincecochon.space-zsk.private | ||
+ | |||
+ | On ajoute ensuite les clefs publiques dans le fichier de zone, et on oublie pas d'incrémentez le numéro de version de la zone | ||
+ | $include /etc/bind/rincecochon.space.dnssec/rincecochon.space-ksk.key | ||
+ | $include /etc/bind/rincecochon.space.dnssec/rincecochon.space-zsk.key | ||
+ | |||
+ | Après on signe le fichier de configuration pour prendre en compte le DNSSEC | ||
+ | |||
+ | dnssec-signzone -o rincecochon.space -k rincecochon.space-ksk ../rincecochon.space rincecochon.space-zsk | ||
+ | |||
+ | Cela nous crée un fichier rincecochon.space.signed. | ||
+ | On modifie ensuite le fichier named.conf.local pour utiliser la zone signée rincecochon.space.signed. | ||
+ | zone "rincecochon.space" { | ||
+ | type master; | ||
+ | file "/etc/bind/rincecochon.space.signed"; | ||
+ | }; | ||
+ | On ajoute également l’option dnssec-enable yes; dans le fichier named.conf.options afin d'activer le DNSSEC. | ||
+ | Et pour finir nous avons communiquer la partie publique de la clé KSK à gandi.net. | ||
+ | |||
+ | On vérifie ensuite le bon fonctionnement du DNSSEC à l'aide du site dnsviz.net, on remarquera lors de ce test que notre serveur dns a un problème avec les requêtes UDP. | ||
+ | |||
+ | [[Fichier:dns.png]] |
Version actuelle datée du 4 décembre 2017 à 10:48
Sommaire
Machine virtuelle
Lors de notre première séance nous avons créé une machine virtuelle Xen Linux sur le dom0 cordouan.insecserv.deule.net Le nom de notre machine virtuelle est RinceCochon et a comme adresse ip 193.48.57.168.
On lui a ensuite alloué un espace disque plus important, 10G pour son /var et 10G pour son /home. On crée 2 dossier de 10G sur cordouan
lvcreate -L10G -nIMA2A5_rincecochon_var virtual lvcreate -L10G -nIMA2A5_rincecochon_home virtual mke2fs /dev/virtual/IMA2A5_rincecochon_var mke2fs /dev/virtual/IMA2A5_rincecochon_home
On rajoute ensuite les nouveaux disque dans rincecochon.cfg
phy:/dev/virtual/IMA2A5_rincecochon_home, xvdb1,w phy:/dev/virtual/IMA2A5_rincecochon_var, xvdb2,w
Dans la machine virtuelle on monte les nouveaux disques à la place du dossier var et home déjà présent en fessant attention à ne pas faire une mauvaise manip se qui aurait pour terrible conséquence de tous casser. Et de nous faire recommencer à 0.
Borne Cisco WEP
Dans un premier temps nous avons configuré l'adresse IP de la borne WIFI
configure terminal interface BVI 1 ip address 10.100.0.4 255.255.255.0 ip default-gateway 10.100.0.254 no shutdown end
Ainsi que le pont qui va nous permettre de relier les différents VLAN
configure terminal bridge irb bridge 1 route ip end
Dans un second temps nous avons configuré les différents ssid et associé à leur VLAN (2 à 6)
configure terminal dot11 vlan-name BORNE_TESTX vlan X dot11 ssid BORNE_TESTX vlan X authentication open guest-mode exit interface dot11Radio 0 no shutdown ssid BORNE_TESTX
Ensuite nous avons spécifié une clé de 128 bits pour chaque VLAN qui sont au nombre de 6.
interface Dot11Radio0 mbssid encryption vlan X mode wep mandatory encryption vlan X key 1 size 128 #clé# transmit_key
On associe les différents vlan sur leurs bridge respectifs.
interface Dot11Radio0.X encapsulation dot1Q X bridge-group X no shutdown exit
Enfin on configure l'interface GigabitEthernet
interface GigabitEthernet0 bridge-group 1 no shutdown exit
Et on associe les différents pont avec le réseau ethernet
interface GigabitEthernet0.X encapsulation dot1Q X bridge-group X no shutdown exit
Borne Cisco WPA-PSK
On a suivi le modéle précédent pour la configuration générale de la borne. Mais nous avons dû intégrer l'encryption WPA
configure terminal dot11 ssid RinceCochon vlan X authentication open authentication key-management wpa wpa-psk ascii 0 mdp mbssid guest-mode exit interface dot11Radio 0 mbssid encryption vlan 2 mode cipher tkip ssid RinceCochon
L'action est réitéré pour chaque groupe
Configuration d'une Zabeth pour le craquage clé WEP
On vérifie dans un premier temps que l'ordinateur reconnaît la clé:
lsusb
Bus 004 Device 017: ID 0846:4240 NetGear, Inc. WG111(v1) rev 2 54 Mbps Wireless [Intersil ISL3887]
grâce aux commandes
ip a iwconfig
La commande suivante permet de reboot le wifi:
/etc/init.d/networking restart
on retrouve les informations liés au réseau WIFI
Ensuite il faut modifier le fichier /etc/network/interfaces
auto wlx000fb5922451 iface wlx000fb5922451 inet static wireless-keymode open wireless-mode managed address 10.100.1.10 netmask 255.255.255.0 gateway 10.100.1.1 wireless-essid BORNE_TESTX wireless-key cléWEP
Téléchargement de arping
apt-get install arping
Envoie de paquets arp avec la borne
arping -W 0.01 10.200.1.1
Craquage clé WEP par force brute
Dans un premier temps nous téléchargeons le package qui va vous permettre le craquage de la clé WEP
apt-get install aircrack-ng
Nous scanons ensuite les échanges des bornes wifi aux alentours pour détecter les bornes utilisant une clé WEP
airodump-ng --encrypt wep wlan0
Grâce à cette commande nous récupérons le bssid de la borne visée ainsi que son canal de diffusion. Ensuite nous lançons la commande qui va nous permettre d'écouter les échanges de la borne wifi
airodump-ng -w out -c 11 --bssid XX:XX:XX:XX:XX:XX wlan0
Cette commande crée des fichiers contenant les échanges de la borne. Ce fichier va être utilisé pour le craquage force brut de la borne.
aircrack-ng out-01.cap
Après quelques minutes nous obtenons la clé WEP de la borne visée, nous permettant ainsi de nous connecter dessus sans problème.
Serveur DNS
Sur le site de gandi nous avons choisi le nom de domaine rincecochon.space. Après configuration nous avons comme serveur DNS primaire : dns.rincecochon.space => 193.48.57.168
Comme tout nom de domaine doit être géré par au moins deux serveurs DNS distincts, pour assurer son bon fonctionnement au cas où l'un des deux serait en panne. Nous avons comme serveur secondaire le dns de gandi : ns6.gandi.net => 217.70.177.40
Afin de configurer le serveur DNS sur la VM nous utilisons la package : bind9.
On configure maintenant le fichier named.conf.option
options { directory "/var/cache/bind"; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; allow-transfer { "allowed_to_transfer"; }; }; acl "allowed_to_transfer" { 217.70.177.40/32; //cette ligne permettra d'autoriser le transfert de zone vers le serveur DNS secondaire “NS6.GANDI.NET” };
Après on modifie named.conf.local afin d'ajouter la “zone” pour notre domaine qui sera lié au serveur DNS
zone "rincecochon.space" { type master; file "/etc/bind/rincecochon.space"; };
On crée maintenant le fichier rincecochon.space qui sera notre fichier de zone
$TTL 259200 @ IN SOA dns.rincecochon.space. postmaster.dns.rincecochon.space. ( 2017100901 ; Version 7200 ; Refresh (2h) 3600 ; Retry (1h) 1209600 ; Expire (14j) 259200 ) ; Minimum TTL (3j) IN NS dns.rincecochon.space. IN NS ns6.gandi.net. IN MX 100 dns.rincecochon.space. IN A 193.48.57.168 dns IN A 193.48.57.168
Après modification de ce fichier, il faut incrémenter le numéro de version pour que la nouvelle version soit bien prise en compte au redémarrage du service bind. Après que notre serveur DNS est opérationnel, nous avons fait la demande de certificat SSL.
Sécurisation de site web par certificat
Après avoir fait la création de notre clé privé et public, on ajoute ensuite la clé publique sur gandi pour qu'il génère 2 certificats.
-CerIntermediaire.crt qui contient le certificat intermédiaire.
-gandi.crt qui contient le certificat.
Dans le fichier /etc/apache2/sites-available/default-ssl.conf on modifie afin de passer en https :
<VirtualHost *:443> ServerName www.rincecochon.space ServerAlias rincecochon.space DocumentRoot /var/www/html SSLEngine on SSLCertificateFile /etc/gandi.crt SSLCertificateKeyFile /etc/monserveur.key SSLCertificateChainFile /etc/CerIntermediaire.crt </VirtualHost>
On utilise ensuite la commande : a2ensite default-ssl.conf afin d'activé la nouvelle configuration sur le site.
Sécurisation de serveur DNS par DNSSEC
On génère ensuite la clef asymétrique de signature de clefs de zone dans le nouveau répertoire rincecochon.space.dnssec
dnssec-keygen -r /dev/urandom -a RSASHA1 -b 2048 -f KSK -n ZONE rincecochon.space
Ainsi que la clef asymétrique de la zone pour signer les enregistrements
dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n ZONE rincecochon.space
On renomme les deux paires de clefs obtenues par
rincecochon.space-ksk.key rincecochon.space-zsk.key rincecochon.space-ksk.private rincecochon.space-zsk.private
On ajoute ensuite les clefs publiques dans le fichier de zone, et on oublie pas d'incrémentez le numéro de version de la zone
$include /etc/bind/rincecochon.space.dnssec/rincecochon.space-ksk.key $include /etc/bind/rincecochon.space.dnssec/rincecochon.space-zsk.key
Après on signe le fichier de configuration pour prendre en compte le DNSSEC
dnssec-signzone -o rincecochon.space -k rincecochon.space-ksk ../rincecochon.space rincecochon.space-zsk
Cela nous crée un fichier rincecochon.space.signed. On modifie ensuite le fichier named.conf.local pour utiliser la zone signée rincecochon.space.signed.
zone "rincecochon.space" { type master; file "/etc/bind/rincecochon.space.signed"; };
On ajoute également l’option dnssec-enable yes; dans le fichier named.conf.options afin d'activer le DNSSEC. Et pour finir nous avons communiquer la partie publique de la clé KSK à gandi.net.
On vérifie ensuite le bon fonctionnement du DNSSEC à l'aide du site dnsviz.net, on remarquera lors de ce test que notre serveur dns a un problème avec les requêtes UDP.