PRA2015 - Configuration des commutateurs
Sommaire
Cahier des charges
Présentation du travail
Le but de la tâche est de configurer le commutateur Cisco 6009 de la salle E306. Le binôme n°4 s'occupe du commutateur de même modèle situé en salle E304.
A l'origine, le matériel sur lequel nous travaillons nous est mis à disposition dans une configuration un peu particulière. En effet la carte superviseur (carte mère) du routeur est livrée avec un système d'exploitation CatOS, tandis que la carte routage (carte fille) fonctionne sous IOS. Dans un premier temps la tâche consistera donc de migrer complètement le routeur vers un système IOS. On pourra par la suite configurer les différents VLANs et la connexion redondante sur les routeurs (groupes 1 & 2). Pour plus de clarté sur l'architecture du réseau, je vous invite à consulter le schéma mis en place par nos collègues du groupe 1.
Matériel utilisé
- Commutateur Cisco 6009
- Un ordinateur muni d'un port série pour la configuration
Progression
Semaine 1 - Prise en main
Dans un premier temps, nous découvrons le matériel à notre disposition et essayons de comprendre comment il fonctionne. Le commutateur Cisco 6009 est constitué d'un rack de 5 baies. Deux d'entre elles contiennent un module permettant le routage sur les modules de ports RJ45. Intéressons nous maintenant à ces deux modules en particulier. Ceux-ci sont constituées d'une carte mère appelée carte superviseur et une carte fille qui est la carte routeur. Chacune des deux cartes contiennent leur propre mémoire flash appelée bootflash. Une carte flash de 20 Mo peut aussi être insérée dans le module. La configuration originelle de ces modules est un peut particulière :
- Module 1 : Un CatOS sur la bootflash de la carte superviseur, et un IOS sur la bootflash de la carte routeur
- Module 2 : Un IOS sur la bootflash de la carte superviseur, et un IOS sur la bootflash de la carte routeur
L'idée est de migrer tout les modules vers des systèmes d'exploitation de type IOS (le seul système utilisé aujourd'hui par Cisco).
Semaine 2 - Installation et configuration des OS
Installation des OS
On démarre le commutateur avec un seul module superviseur branché. On en configurera un seul à la fois. Nous avons décidé de configurer le module avec CatOS en premier.
Nous passons en mode enable avec la commande du même nom, pour ensuite associer une IP à l'interface sc0. Avec celle ci nous pourrons transférer les fichiers avec un ordinateur (tutur06) via TFTP.
console> enable console (enable)> set interface sc0 192.168.0.1 255.255.255.0
A cause d'une erreur (bad device info block), nous avons du formater la flash pour pouvoir la lire et écrire dessus. En effet chaque OS a son propre système de fichier.
console (enable)> format slot0:
On peut maintenant copier le binaire contenant l'OS à installer. Pour cela on configure une IP dans le même réseau que l'interface sc0 sur tutur06. L'ordinateur est déjà configuré pour transférer des fichiers par TFTP. Ici nous avons configuré l'IP 192.168.0.2/24.
console (enable)> copy tftp slot0: console (enable)> 192.168.0.2 console (enable)> "emplacement du fichier"
A partir de là, on peut donc booter directement sur la carte sous IOS. Pour cela il faut interrompre le boot automatique sur CatOS pour indiquer au système de boot sur la carte IOS.
Comme il y a eu un problème de carte avec le deuxième binôme, nous avons du re-formater leur carte au format CatOS, pour cela il a fallu booter en CatOS, la formater sous CatOS et leur remettre les bons fichiers sur la carte via tftp.
A partir de là nous avons pu, de la même manière que précédemment, formater la deuxième au format IOS puis y mettre les fichiers IOS via tftp. En outre, nous avons indiqué au système de boot sur la carte flash via la directive :
BOOT=slot0:<CHEMIN DU FICHIER.bin>
Configuration des OS
La configuration réseau du routeur se déroule en 3 étapes.
Dans un premier temps, on configure les liaisons trunk. Il s'agit ici de la liaison qui relie le commutateur au routeur en E306, sur l'interface 4/3, et la liaison cable qui relie le commutateur au routeur en E304 sur l'interface 7/2. On écrit donc pour chaque interface
conf t int Gi4/3 switchport switchport mode trunk switchport trunk allowed vlan 11-20,110,130 no shut exit
int Gi7/2 switchport switchport trunk encapsulation dot1q switchport mode trunk switchport trunk allowed vlan 11-20,110,130 no shut exit
Il faut ensuite créer les VLAN, par exemple :
conf t vlan 13 name vlan13 exit
On fait ceci pour les VLAN 11 à 20, puis 110 et 130. Une fois qu'ils sont déclarés, on les attribue à un port physique du commutateur :
int Gi4/13 switchport access vlan 13 no shut exit
Le schéma physique est le suivant :
- VLAN11 : Gigabit 4/11
- VLAN12 : Gigabit 4/12
- VLAN13 : Gigabit 4/13
- VLAN14 : Gigabit 4/14
- VLAN15 : Gigabit 4/15
- VLAN16 : Gigabit 4/16
- VLAN17 : Gigabit 4/17
- VLAN18 : Gigabit 4/18
- VLAN19 : Gigabit 4/19
- VLAN20 : Gigabit 4/20
- VLAN 110 : Gigabit 4/1
Semaine 3
Nous avons commencé par créer une VM Xen sur le serveur Cordouan :
xen-create-image --hostname=chimay --ip=193.48.57.163 --netmask=255.255.255.240 --gateway=193.48.57.174 --dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --passwd
- Notre IP : 193.48.57.163
- Masque : 255.255.255.240
- Passerelle : 193.48.57.174
Nous avons ensuite crée 2 partitions LVM, home et var.
lvcreate -L 10G -n /dev/virtual/ima5-chimay-home -v lvcreate -L 10G -n /dev/virtual/ima5-chimay-var -v
Il faut enfin modifier le fichier /etc/xen/chimay.cfg, y rajouter les partitions LVM :
disk = [
'phy:/dev/virtual/ima5-chimay-var,xvdb,w'
'phy:/dev/virtual/ima5-chimay-home,xvdb,w' ]
dans vif, rajouter bridge=IMA5sc
Enfin, une fois la VM lancée, on y ajoute le serveur apache, le serveur SSH et le serveur DNS :
apt-get install apache2 apt-get install openssh apt-get install bind9
On active la possibilité de se connecter par SSH en tant que root directement en ajoutant dans /etc/ssh/sshd_config :
PermitRootLogin yes
Semaine 4
Nous avons commencé par louer un nom de domaine chez Gandi. Comme le thème est la bière et que nous avons choisi de nommer notre VM Chimay, nous avons, pour des raisons légales, choisi de louer le domaine michay.lol.
Installation du serveur Apache et du certificat SSL
Nous avons commencé par configurer Apache et y installer un certificat SSL. A cet effet, nous avons commencé par générer un fichier .csr avec OpenSSL :
openssl req -nodes -newkey rsa:2048 -sha256 -keyout michay.lol.key -out michay.lol.csr
Les domaines certifiés sont michay.lol et www.michay.lol.
On fournit la .csr à Gandi qui la signe et valide et nous renvoie un .crt. On choisit de le mettre à côté de la .key, et on supprime la .csr.
On poursuit ensuite en activant le module SSL d'Apache :
a2enmod ssl
Il faut ensuite configurer Apache pour écouter sur le port 443, dans /etc/apache2/ports.conf :
<IfModule mod_ssl.c> Listen 443 NameVirtualHost 193.48.57.163:443 </IfModule>
Enfin, on ajoute un VirtualHost servant le contenu du dossier /var/www/www.michay.lol/ sur le port 443, dans /etc/apache2/sites-available/000-michay.lol-ssl.conf :
<VirtualHost *:443> **** On veille à mettre un wildcard, sinon le certificat SSL n'est pas chargé quand l'adresse est un FQDN. **** ServerName www.michay.lol **** Domaine et Alias **** ServerAlias michay.lol DocumentRoot /var/www/www.michay.lol/ **** Dossier contenant les fichiers du site **** CustomLog /var/log/apache2/secure_access.log combined **** Localisation des logs **** SSLEngine on **** Activation du SSL **** SSLCertificateFile /etc/ssl/certs/www.michay.lol.crt **** Chargement du certificat signé par Gandi **** SSLCertificateKeyFile /etc/ssl/private/www.michay.lol.key **** Clé privée correspondant au certificat combiné à la PEM **** SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem **** Clé publique émise par Gandi **** SSLVerifyClient None </VirtualHost>
On peut alors remarquer que la connexion sécurisée s'affiche en vert dans la barre d'adresse : le certificat est valide. La connexion est sécurisée et le site est de confiance. On remarque notamment la date de validité, ici le certificat est valide pour 1 an.
On peut notamment voir toute la chaîne de certification !
Mise en place du serveur DNS et de DNSSEC
Toute la configuration du serveur DNS s'effectue dans le dossier /etc/bind/ :
Nous avons crée un dossier /etc/bind/zones dans lequel nous stockons nos fichiers de zone DNS.
zone db.michay.lol :
$TTL 604800
@ IN SOA ns.michay.lol. root.michay.lol. (
2015102001 ; Serial
86400 ; Refresh
3600 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
$include /etc/bind/michay.lol.dnssec/michay.lol-ksk.key
$include /etc/bind/michay.lol.dnssec/michay.lol-zsk.key
@ IN NS ns.michay.lol.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.163
www IN A 193.48.57.163
god IN A 193.48.57.163
ns IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535
www IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535
god IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535
@ IN A 193.48.57.163
@ IN AAAA 2001:660:4401:60bb:216:3eff:fe73:e535
et la zone inverse pour la résolution des adresses IP, 57.48.193.in-addr.arpa :
$TTL 604800
@ IN SOA ns.michay.lol. root.michay.lol. (
2015102001 ;serial
14400 ;refresh
3600 ;retry
604800 ;expire
10800 ;minimum
)
57.48.193.in-addr.arpa. IN NS ns.michay.lol.
57.48.193.in-addr.arpa. IN NS ns6.gandi.net.
163 IN PTR michay.lol.
On peut enfin ajouter les zones dans le fichier de configuration principale de bind, /etc/bind/named.conf.local :
zone "michay.lol" {
type master;
file "/etc/bind/zones/db.michay.lol.signed";
allow-transfer { 217.70.177.40; };
notify yes;
};
zone "57.48.193.in-addr.arpa" IN {
type master;
file "/etc/bind/zones/57.48.193.in-addr.arpa";
allow-transfer { 217.70.177.40; };
};
Notons que par rapport à la configuration minimale des fichiers, nous avons rajouté quelques lignes, en particulier :
- allow-transfer { 217.70.177.40; }; notify yes; : Déclaration dans la configuration de l'adresse IP du DNS secondaire chez Gandi (ns6.gandi.net)
- @ IN NS ns6.gandi.net. et 57.48.193.in-addr.arpa. IN NS ns6.gandi.net. dans les fichiers de zone pour le DNS secondaire
On enchaîne enfin sur la sécurisation du serveur DNS avec DNSSEC, pour éviter qu'un pirate puisse par exemple modifier de manière invisible l'IP de redirection du domaine. Pour ce faire, on crée 2 clés : une Key Signing Key (KSK) et une Zone Signing Key (ZSK). On utilisera l'option -r /dev/urandom, pour utiliser la génération pseudo-aléatoire (au lieu de /dev/random par défaut), ce qui accélère grandement la génération sur notre système.
Génération de la KSK :
dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE michay.lol
Génération de la ZSK :
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE michay.lol
On renomme les 4 clés générées pour se retrouver dans notre dossier avec les fichiers suivants :
root@chimay:/etc/bind/michay.lol.dnssec# ls total 24 drwxr-sr-x 2 root bind 4096 Oct 20 15:10 . drwxr-sr-x 4 root bind 4096 Oct 21 18:12 .. -rw-r--r-- 1 root bind 603 Oct 20 13:48 michay.lol-ksk.key -rw------- 1 root bind 1774 Oct 20 13:48 michay.lol-ksk.private -rw-r--r-- 1 root bind 429 Oct 20 13:48 michay.lol-zsk.key -rw------- 1 root bind 1010 Oct 20 13:48 michay.lol-zsk.private
On ajoute le chemin d'accès aux clés publiques .key dans le fichier de zone db.michay.lol, en ajoutant ces lignes après la déclaration SOA :
$include /etc/bind/michay.lol.dnssec/michay.lol-ksk.key $include /etc/bind/michay.lol.dnssec/michay.lol-zsk.key
On fournit les clés publiques KSK et ZSK à Gandi pour qu'il puisse les propager sur l'internet (Rubrique "Gérer DNSSEC").
Pour finir, on signe la zone avec la commande dnssec-signzone :
dnssec-signzone -o michay.lol -k michay.lol.dnssec/michay.lol-ksk zones/db.michay.lol michay.lol.dnssec/michay.lol-zsk
Cela crée un fichier db.michay.lol.signed. Il ne nous reste plus alors qu'à modifier le fichier de configuration named.conf.local pour lui dire d'utiliser db.michay.lol.signed à la place de db.michay.lol.
Après test (juste ici), on constate que la mise en place de DNSSEC est validée. Après quelques modifications, il reste 1 "erreur" (pas de record MX défini, on pourrait supprimer l'erreur en mettant l'ip des serveurs mails Gandi), et 2 warnings (1 warning car le glue record du serveur DNS secondaire (ns6.gandi.net) ne peut pas être défini sur l'interface Gandi ; 1 warning parce que l'utilitaire considère que la valeur du refresh dans le SOA de la zone est trop haute).
Piratage des bornes wifi
Crackage WEP
Nous avons utilisé ici la célèbre distribution Kali pour effectuer le crack. On peut afficher l'état des interfaces réseau avec la commande iwconfig. Dans un premier temps, il faut passer l'interface wifi en mode monitor.
airmon-ng start wlanX
wlanX est l'interface wifi utilisée pour l'attaque. Si un problème survient, il peut peut être réglé en exécutant la commande :
airmon-ng check kill
L'étape suivante consiste à récupérer des vecteurs d'initialisation contenus dans les datas transmises. Pour cela, on peut afficher le traffic wifi avec la commande:
airodump-ng wlan5mon
Cette commande affiche les différents points d'accès ainsi que les clients connectés qui communiquent par Wifi. L'idée est maintenant de capturer et enregistrer les paquets du point d'accès qui nous intéresse. Dans notre cas, nous voulons cracker cracotte03. Pour cela, nous exécutons la commande :
airodump-ng --bssid 00:23:5E:1E:05:42 --ch 7 --write fichier wlanXmon
Nous laissons cette commande fonctionner durant le crack. Nous pouvons ouvrir un autre terminal. En théorie, il est nécessaire à cette étape de stimuler le traffic wifi pour récupérer des paquets. Dans le cadre de notre TP cette étape n'est pas nécessaire car le traffic est déjà très important. Nous pouvons passer directement au crackage de la clé. Dans le nouveau terminal, nous entrons :
aircrack-ng fichier*.cap
Les deux commandes peuvent fonctionner en parallèle. Nous n'avons plus qu'à attendre. Au bout d'un certain temps (~48k IVs), nous obtenons la clé :
KEY FOUND! [ 55:55:55:55:55:55:55:55:55:55:55:51:11 ]
Connexion à l'AP autorisé
On modifie le fichier /etc/network/interfaces
On commente #auto eth0
On configure wlan0 :
auto wlan0 iface wlan0 inet static address 172.26.79.63 netmask 255.255.240.0 gateway 172.26.79.254 wireless-essid troubadour wireless-mode managed
La connexion fonctionne sans soucis, on ping la gateway 172.26.79.254 et on accède à internet, en particulier les sites IPv4.
Connexion à l'AP filtré
On cherche cette fois à se connecter à un AP Wifi filtré par adresses MAC sur lequel on a pas le droit car notre adresse MAC n'est pas autorisée.
On modifie l'adresse MAC en prenant une adresse volée à l'aide du social engineering :
ifconfig wlan0 down ifconfig wlan0 hw ether 00:15:af:e7:19:f3 ifconfig wlan0 up
On arrive ensuite toujours à ping la gateway et accéder à internet sans soucis !
Crackage WPA
De la même manière que pour le crackage WEP, dans un premier temps il faut passer l'interface WiFi en mode moniteur. Vous pouvez voir la démarche à suivre dans la partie Crackage WEP au dessus. Ensuite, on récupère le traffic de l'AP ciblé dans un fichier. Le but ici consiste à récupérer des données particulières à l'encryption WPA. Cette donnée s'appelle le handshake. Le handshake est transmis lors de l'authentification d'un client sur le point d'accès. En théorie on force le passage de ce handshake en envoyant des paquets de désauthentification d'un client au point d'accès. Dans le cadre du TP le handshake est transmis en permanence. On voit alors dans la fenêtre de airmon-ng que le handshake WPA a été récupéré.
