Cahier groupe n°8 : Différence entre versions

Version du 12 novembre 2015 à 11:06

Présentation de la tâche particulière

Nous avons la responsabilité de configurer un pont pour les IMA5sc et les IMA5sa sur le serveur de virtualisation Xen ainsi que sur les différentes machines prénommées ZabethXX.

Matériel utilisé pour la tâche particulière

Suivi de l'avancement du TP

Semaine 1

Nous avons essayé de configurer un bridge sur l'une des Zabeth. Nous nous sommes heurtés au fait que le bridge prend l'adresse MAC la plus basse des deux interfaces Ethernet. Or eth0 (carte mère) a l'adresse MAC la plus haute. Donc on n'arrivait pas à accéder au net en DHCP.

Semaine 2

• Une configuration a été réussie sur une Zabeth avec l'aide de M. Redon. Cependant, cela nécessite de forcer l'adresse MAC du bridge à être identique à celle de l'interface eth0. Cette configuration n'est pas souhaitable après discussion avec l'enseignant. Alternative proposée : réaliser une mascarade permettant aux périphériques connectés à eth1 de ne pas apparaître sur le réseau mais de quand même pouvoir y accéder via modification des paquets et passage via eth0.

Équivalence ports physiques interfaces

• On a également recherché sur le serveur Xen les ports eth grâce à ifconfig et mii-tool. Ceci était nécessaire pour pouvoir connecter les équipements au bridge IMA5sc créé, ainsi que d'indiquer aux IMA2a5 les ports de leur bridge. Le schéma suivant permet de donc retrouver la localisation physique des ports concernés sur la machine.
• L'installation de la machine virtuelle Xen a aussi été réalisée avec pour :
  • hostname : KEKETTE
  • nameserver : 93.48.57.48
  • ip : 193.48.57.168
  • netmask : 255.255.255.240
  • password : ********

• Afin de mettre en place la mascarade, la méthode suivante à été appliquée :
  

  Schéma de principe de la mascarade
  • Adressage manuel d'eth1 en 192.168.10.1/24 via /etc/network/interfaces pour une modification permanente.
  • Modification de l'iptable avec les commandes fournies dans le cours et adaptées pour une telle utilisation, placée dans /sbin/iptables-restore avec le fichier /etc/network/if-pre-up.d/iptables. Ceci à été fait en partie en suivant la procédure suivante
  • Activation l'IPv4 packet forwarding en de-commentant la ligne appropriée dans le fichier /etc/sysctl.conf
  • Installation et configuration d'un serveur dhcp, avec le paquet isc-dhcp-server et en le configurant sur le réseau 192.168.10.0. Ceci à été fait en partie en suivant la procédure suivante

Par la suite un script de déploiement sur les autres machines à partir d'une zabeth correctement configuré à été mis en place. Le script ainsi que le fichier de configurations sont disponibles en annexe. Le déploiement et le fonctionnement à été testé et validé à ce jour. Il suffit donc pour accéder au réseau de venir ce relier physiquement avec la carte réseau additionnelle d'une machine, de laisser la procédure dhcp s'effectuer, et d'ajouter le proxy polytech aux paramètres de connexion.

Semaine 3

On a effectué le premier lancement de la machine virtuelle. On y a rajouté la passerelle nécessaire (193.48.57.174) ainsi que le nom du bridge afin de récupérer un accès internet. On a installé les paquets ssh, apache2 et bind. Puis demande du nom de domaine sur Gandi.net, ainsi que la création des clés sur la VM afin de demander la génération du certificat SSL.

Semaine 4

Services internet

On a configuré apache et bind à l'aide d'un tutoriel disponible sur la documentation Ubuntu. Après cela, on a réalisé les fichiers de zones pour notre zone kekette.lol et la zone inverse. On a sécurisé le DNS avec DNSsec. Pour cela, il a fallu générer la clé KSK privée et publique et la ZSK privée et publique. On donne à Gandi les deux clés publiques. Ensuite, il faut signer les enregistrements de la zone à l'aide de dnssec-signzone. A la suite de cela, un fichier kekette.lol.signed est généré, c'est pourquoi il faut ensuite modifier le fichier /etc/bind/named.conf.local afin qu'il prenne en compte le fichier kekette.lol.signed au lieu de kekette.lol. Après quelques corrections, nous arrivons à avoir notre dnssec fonctionnel, en effet, sur ce lien, chacun peut constater que notre domaine ne cause aucune erreur. Cependant, deux warnings restent présents mais ils sont sans importance. Le premier warning indique juste qu'il n'y a pas de glue pour le DNS de Gandi. Le deuxième indique juste que les versions des serveurs de noms sont différentes.

Réalisations

Cryptage de données

A l'aide de GParted, une unique partition avec pour système de fichiers ext3 est créée sur la carte SD. On a encrypté la partition /dev/sdb1. On initialisé le volume et un nom de mapping apparaît dans /dev/mapper/. On a créé un système de fichiers au format ext4. On a monté le système de fichiers. On y a inséré un fichier quelconque. On l'a démonté. Puis on a demandé au binôme de Jean et Flavien de vérifier qu'il est impossible d'accéder au fichier inséré précédemment sans la clé de cryptage.

Semaine 5

Sécurisation de données

Après la création des trois partitions, nous avons créé le RAID 5 logiciel à l'aide de mdadm. Nous avons un léger soucis : le volume md0 s'est transformé en md127 pour une raison obscure. Nous avons édité le fichier /etc/mdadm/mdadm.conf. Après un redémarrage de la VM, en regardant le contenu du fichier /proc/mdstat, nous avons bien notre RAID actif :

md127 : active raid5 xvdd[0] xvdf[2] xvde[1]

Crackage WEP

Nous avons rélalisé cette semaine le craquage de clé wep, en même temps que tout le monde. On lance donc successivement, après avoir désactivé les gestionnaires de reseaux :

airmon-ng start wlan-0
airodump-ng --encrypt wep wlan0 //recherche de cracotte08, son bssid son canal
airodump-ng -w out -c 10 --bssid 00:23:5e:1e:005:47 wlan0 //creation du fichier *.cap
aircrack-ng out-01.cap // une fois assez de d'ivs collectés

on obtient alors :

Annexes

Média:Masquerade.zip