Rapport DHCP (Agnon Kurteshi)
Partie 1
Capture de paquet DHCP
1.
afin de capturer que les paquets DHCP, il faut rajouter un filtre dans WireShark
comme l’image ci-dessus.
2.
isc@debian:~$ ip route get [Link]
Après cette commande, nous avons le message suivant qui s’affiche :
RTNETLINK answers: Network is unreachable
1
3.
Ce message signifie que l’hôte n’a pas de route pour communiquer avec le DNS,
donc pas de “default gateway”. Cela est dû au fait que l’hôte n’a pas d’adresse
IP.
5.
Après la commande suivante :
sudo dhclient -v eth0
nous avons le message suivante qui s’affiche :
DHCPDISCOVER on eth0 to [Link] port 67 interval 15
DHCPOFFER of [Link] from [Link]
DHCPREQUEST for [Link] on eth0 to [Link] port 67
DHCPACK of [Link] from [Link]
Tous ces messages font parties du protocol DHCP et sont les différentes étapes
de demande d’un IP jusqu’à l’obtention de cette dernière.
6.
Oui, la transaction DHCP a réussi, car on peut voir qu’il y a eu un DHCPACK
qui signifie qu’il y a bien eu un échange d’adresse IP.
7.
On peut le voir avec un ping du DNS de CloudFlare ([Link]).
--- [Link] ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 4.251/4.811/5.691/0.552 ms
Tout les paquets envoyés ont atteint le DNS.
2
8.
Pour la durée du bail :
Pour le nom de host:
Pour les options demandées par le client
Pour le serveur DNS:
Pour la passerelle:
3
Attaque par épuisement du pool DHCP
1.
2.
sudo dhcpig -a -i -c eth0
3.
sudo dhcpig -a -i -c eth0
-a, --show-arp ... detect/print arp who_has (off)
-i, --show-icmp ... detect/print icmps requests (off)
-c, --color ... enable color output (off)
4.
La commande dhcpig va lancer des requêtes DHCP sur le réseau, et donc, va
récupérer toutes les adresses IP disponibles. Toutes les requêtes Discover et
Request sont en broadcast, alors que les requêtes Offer et Ack sont en unicast.
On peut remarquer cela avec WireShark, où l’on peut voir plusieurs fois le DORA
(Discover, Offer, Request Ack).
5.
Oui, c’est le résultat attendu, car on lance des requêtes DHCP avec comme
source [Link], et la destination est [Link] qui signifie que la requête
est en broadcast. Donc forcément, les requêtes vont passer entre le switch et le
serveur DHCP.
4
6.
Voici le comportement :
Ce que l’on voit ici, c’est que H2 envoie des requêtes DHCP Discover, mais il n’y
a aucune réponse du serveur DHCP, car il n’a plus d’adresses IP à disposition.
7.
dhcpig -x 10 -i -a -c eth0
Attaque par épuisement du pool DHCP
1.
Pour activer DHCP snooping, on fait les commandes suivantes sur le switch.
enable
conf t
ip dhcp snooping
ip dhcp snooping vlan 1
interface Gi 0/0
ip dhcp snooping trust
DHCP Snooping va supprimer le trafic DHCP jugé inacceptable.
Afin de choisir quelles interfaces vont être trutées, on doit se mettre sur l’interface
avec “interface Gi x/x”, et ensuite faire la commande “ip dhcp snooping trust”.
2.
la commande :
sh ip dhcp snooping
va nous montrer la configuration des interfaces où le DHCP snooping trust est
activé.
DHCP snooping trust/rate is configured on the following Interfaces:
Interface Trusted Allow option Rate limit (pps)
----------------------- ------- ------------ ----------------
GigabitEthernet0/0 yes yes unlimited
5
3.
Après avoir relancé l’attaque, on peut voir que le poste kali n’arrive plus à
récuperer des adresses IP. On peut déjà le voir avec WireShark, où on ne voit
aucune requête passer le switch jusqu’au serveur DHCP. Mais par contre, H2 et
H1 peuvent faire des requêtes DHCP et recoivent des réponses du serveur.
4.
Voici le log du switch après l’attaque depuis kali :
*Oct 20 [Link].893: %DHCP_SNOOPING-5-DHCP_SNOOPING_MATCH_MAC_FAIL: DHCP_SNOOPING drop mess
Ce message dit que l’addresse MAC du client contenu dans le champ chaddr
(adresse matériel du client) du message DHCP ne correspond pas à l’adresse
MAC source de la trame où la requête DHCP est encapsulé. l’inteface où le
message DHCP a été créé n’est pas la même que l’interface par lequelle la requête
DHCP a vraiement été créé.
Et donc, pour cette raison, les requêtes de l’attaques sont supprimées.
Bilan et perspectives
1.
Le port security permet de contrôler les adresses MAC autorisées sur un port.
Et comme le DHCP Snooping lui aussi, permet de truster certains ports, cela
fournira une double couche de sécurité au niveau de la couche 2.
2.
Il y a le DHCP Spoofing, qui consite à attribuer des paramètres de configuration
DHCP non autroisées sur le réseau. Ensuite, l’attaquant devient la passerelle par
défaut de l’hôte, et tout ce que l’hôte fait passe par l’attaquant. DHCP Spoofing
permet de se protéger contre cette attaque. En activant cette fonctionnalité, on
peut choisir quel port sera approuvé, et donc, si l’attaquant se connecte à un
port du commutateur, il n’est pas autorisé à recevoir des réponses DHCP, et
si une fausse réponse DHCP d’un attaquant tente d’entrer dans un port non
approuvé, le port sera désactivé.
6
Partie 2
Configuration du routage et relai
1.
Non, car de base, les interfaces du routeur ne sont pas actifs.
2.
Afin que les paquets DHCP puissent passer le routeur il faut faire une configura-
tion du routeur avec les commandes suivantes :
Pour la configuration de l’interface fa0/0 (où il y a les postes clients):
enable
conf t
interface fa 0/0
ip address [Link] [Link]
no shut
ip helper-address [Link]
Pour l’interface fa0/1 (où il y a le serveur DHCP) :
enable
conf t
interface fa 0/1
ip address [Link] [Link]
7
no shut
Cela permet d’activer le DHCP relay sur le routeur et les interfaces du routeur.
Après ces commandes, on récupère ceci avec le WireShark :
Il n’y a que les requêtes DISCOVER qui passe, car le serveur DHCP n’est
toujours pas configuré.
Les requêtes après, avoir passé le routeur, sont en unicast. On peut le voir avec
WireShark où la destination des requêtes est le serveur DHCP.
Configuration du service DHCP
1.
Avec de configurer le serveur DHCP avec des adresses IP d’un autre sous-réseau,
on va devoir aller configurer un fichier avec la commande suivante :
sudo nano /etc/dhcp/[Link]
et rajouter ces lignes dans le fichier :
subnet [Link] netmask [Link] {
range [Link] [Link];
option routers [Link];
}
Avec ceci, on va configurer les adresses IP pour le réseau [Link].
Pour que les modifications soient prises en compte, il faut redémarrer le serveur
DHCP avec la commande :
sudo /etc/init.d/isc-dhcp-server restart
Maintenant que les adresses IP sont configurées, on va devoir ajouter une route
depuis le serveur DHCP vers le routeur.
Voici la commande à utiliser :
sudo ip route add [Link]/24 via [Link]
Maintenant, en faisant une requête DHCP à partir du post H2, on voit que l’on
reçoit l’adresse IP avec DORA.
8
DHCPDISCOVER on eth0 to [Link] port 67 interval 8
DHCPOFFER of [Link] from [Link]
DHCPREQUEST for [Link] on eth0 to [Link] port 67
DHCPACK of [Link] from [Link]
bound to [Link] -- renewal in 148 seconds.
3.
Oui, l’attaque peut encore avoir lieu.
