Cahier groupe n°8 : Différence entre versions

Version actuelle datée du 10 décembre 2015 à 09:38

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]

Nous avons testé ensuite la perte d'une partition. Nous remarquons dans le fichier /proc/mdstat que le RAID 5 est toujours actif mais qu'il ne dispose que de seulement deux partitions actives.

md127 : active raid5 xvde[1] xvdf[2] xvdd[0](F)
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]

Crackage WEP

Nous avons réalisé 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 7 --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 :

Semaine 6

Réalisation en même temps que les autres groupes du cassage de clé WPA. Récupération d'un hash avec airodump-ng, puis réalisation d'un dictionnaire réalisé simplement avec un code C affichant sur la sortie standard les nombres de 00000000 à 99999999. La sortie standard est redirigée dans un fichier texte, puis les test sont effectués sur deux pc en parallèle, en commençant à deux endroits différents. Après de longues minutes, on obtient enfin :

Semaine 7

Nous avons tout d'abords mis a jour le serial du fichier de zone de dns, afin de ne pas obtenir d'erreur sur notre certification après un délai de plus de 30 jours.

Par la suite, nous avons procédé à l’installation de freeradius, sa configuration avec l'ajout des deux bornes wifi (10.10.10.1 et .2) et de deux "secret" différents dans client.conf, le choix de la méthode peap dans le fichier eap.conf, et enfin l'ajout d'utilisateurs/mdp dans le fichier user.

Par la suite la configuration du sous reseau et SSID des bornes wifi à été réalisé. Les commandes présentes dans le sujet, agrémentés de quelques suppléments afin de rendre le SSID visible, et de faire le lien entre l'interface gigabits et le sous reseau wifi permettent d'obtenir une config fonctionnelle.

Enfin, la configuration du /etc/network/interfaces afin de pouvoir se connecter au réseau wifi fraîchement mis en place. La config est donc fonctionnelle une fois un ifup wlan0 lancé. L'installation du paquet isc-dhcp-server à aussi été effectué, suivi d'une configuration.

Semaine 8

Comme visible sur les captures Android suivantes, la configuration du serveur dhcp installé sur l'EeePC à été terminé et est fonctionnelle. L'Eeepc prend l'adresse ip 172.20.18.5 et attribue des adresses entre .20 et .40. L'installation d'asterisk à aussi été effectué mais sa configuration n'a pas été terminé.

L'installation de paquets nécessaire pour la récupération de données sur le formulaire Facebook à aussi été effectué sur notre zabeth

Semaine 9

En ajoutant les lignes suivantes au fichier 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 = pifoufou
   username = pifoufou
   secret=XXX
   context = work

   [1002]
   type=peer
   host=dynamic
   dtmfmode=rfc2833
   disallow=all
   allow=ulaw
   fullname = pifoufoufou
   username = pifoufoufou
   secret=XXX
   context = work

et dans le fichier extensions.conf :

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

Une fois un client softphone configuré (X-lite pour windows) et CSipSimple pour android sur une tablette de projet emprunté au groupe 9, on peut alors passer des appels. Le log suivant d'asterisk (-cvvvr) montre bien le bon fonctionnement.

 == Using SIP RTP CoS mark 5
   -- Executing [1002@work:1] Dial("SIP/1001-00000004", "SIP/1002,20") in new stack
 == Using SIP RTP CoS mark 5
   -- Called SIP/1002
   -- SIP/6002-00000005 is ringing
[ Dec  8 01:42:25] NOTICE[8812]: chan_sip.c:27846 handle_request_subscribe: Received SIP subscribe for peer without mailbox: 1001
   -- Nobody picked up in 20000 ms
   -- Executing [1002@work:2] Hangup("SIP/1001-00000004", "") in new stack
 == Spawn extension (work, 1002, 2) exited non-zero on 'SIP/1001-00000004'
 == Using SIP RTP CoS mark 5
   -- Executing [1002@work:1] Dial("SIP/1001-00000006", "SIP/1002,20") in new stack
 == Using SIP RTP CoS mark 5
   -- Called SIP/1002
   -- SIP/1002-00000007 is ringing
      > 0xb694bff0 -- Probation passed - setting RTP source address to 172.20.18.24:4002
      > 0xb694bff0 -- Probation passed - setting RTP source address to 172.20.18.24:4002
   -- SIP/1002-00000007 answered SIP/1001-00000006
   -- Remotely bridging SIP/1001-00000006 and SIP/1002-00000007
      > 0xb694bff0 -- Probation passed - setting RTP source address to 172.20.18.24:4002
      > 0xb690fc50 -- Probation passed - setting RTP source address to 172.20.18.23:49449
      > 0xb690fc50 -- Probation passed - setting RTP source address to 172.20.18.23:49449

Démonstration de la communication:

Annexes

Média:Masquerade.zip