PhilippeTeuwen at 00:06, 26 February 2008

2008-02-26T00:06:49Z

New page

''Converted with [[MediaWiki#HTML-WikiConverter|HTML::WikiConverter::MediaWiki]] from my old phpwiki site''
----
== Alleï hackons un peu le bastringue... ==

Spoofing d'un paquet HELLO de AODV: cf 5.2 & 6.9 of [http://www.faqs.org/rfcs/rfc3561.html RFC:3561]

hping2 --id 0 \
--dontfrag \
--udp --baseport 654 --keep --destport 654 \
--spoof <IP SRC> \
--ttl 1 \
--data 20 \
--file packet.raw \
255.255.255.255

avec un fichier "packet.raw" qui contient les bytes suivants:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|A| Reserved |Prefix Sz| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2
R Repair flag; used for multicast.
A Acknowledgment required; see sections 5.4 and 6.7.
Reserved Sent as 0; ignored on reception.
Prefix Size If nonzero, the 5-bit Prefix Size specifies that the
indicated next hop may be used for any nodes with
the same routing prefix (as defined by the Prefix
Size) as the requested destination.
Hop Count The number of hops from the Originator IP Address
to the Destination IP Address. For multicast route
requests this indicates the number of hops to the
multicast tree member sending the RREP.
**In case of HELLO message: 0**
Destination IP Address
The IP address of the destination for which a route is supplied.
**In case of HELLO message: The node's IP address.**
Destination Sequence Number
The destination sequence number associated to the
route.
**In case of HELLO message: The node's latest sequence number.**
Originator IP Address
The IP address of the node which originated the RREQ
for which the route is supplied.
Lifetime The time in milliseconds for which nodes receiving
the RREP consider the route to be valid.
**In case of HELLO message: ALLOWED_HELLO_LOSS * HELLO_INTERVAL**

Par exemple pour annoncer la machine 10.11.12.13:

hping2 --id 0 \
--dontfrag \
--udp --baseport 654 --keep --destport 654 \
--spoof 10.11.12.13 \
--ttl 1 \
--data 20 \
--file packet.raw \
255.255.255.255

avec un fichier "packet.raw" qui contient les bytes suivants: (forgé a l'aide de hexedit)

02 00 00 00
0A 0B 0C 0D
00 00 00 01
0A 0B 0C 0D
00 00 0B B8

Si on se sert de cette méthode, Ethereal confirme que les paquets spoofés sont bit à bit égaux avec ceux envoyés par kernel_aodv

==== Remarques ====

* hping accepte aussi un --sign "data" plutot que de passer par un fichier mais specifier --sign $'\x02\x00...' ne marche pas car le char null emm... le bazar
* pour surveiller la table AODV je regarde /proc/aodv/route_table
* j'essaye aussi de lancer kernel_aodv par modprobe car le script /etc/init.d/kaodv gèle un peu trop de params à mon goût dans ce cadre-ci.
* Il me semble que d'après le draft le daemon n'est pas obligé d'intégrer l'info HELLO venant des voisins.

=== Essai réalisé au laboratoire de Bombolong ===

==== Configuration ====

* le client A est configuré comme s'il l'avait été par DHCP servi par B
** IP 10.3.56.77 NETMASK 255.255.255.255
** route add 10.3.56.74 eth1
** route add default gw 10.3.56.74
** PAS de AODV
* la machine B
** IP 10.3.56.74
** KAODV
* la machine C
** broadcast des HELLO forgés "venant de A" D ne voit pas ces paquets B voit ces paquets c'est le but recherché!!
* la machine D
** IP 10.2.206.108
** KAODV

==== Résultats ====

Si D veut pinger A, ça marche! D'après ethereal sur B voici ce qui se passe:

* D envoie un RREQ pour trouver A
* B envoie un RREP a D pour dire qu'il peut joindre A via B
* D ajoute à sa table que A est à 2 hops via B
* D icmp echo request à A via B
* B relaye echo request
* A icmp echo reply à D via B
* B relaye echo reply
* D est content et moi aussi :-)

==== Remarques ====

* DHCPd est-il capable de configurer A avec le bon tunnel IPA-IPB?
* kaodv semble travailler au dessus de la pile UDP/IP car il broadcast sur 255.255.255.255 qui n'est pas accessible d'apres le contenu de la table de routage et lorsque je forge les paquets HELLO je dois ajouter cette route sinon Network unreachable!
* la machine qui génère les paquets HELLO par hping ne voie pas ses propres paquets, ce qui est assez gênant si on veut qu'une machine complète ses routes elle-même. C'est logique il faut s'assurer que l'interface "lo" soit gérée par AODV (''pas'' de aodv_dev=...) et l'utilise effectivement (use_lo=1) pour que ça marche. cf KernelAodvHack pour plus de détails.
* physiquement lors du test les machines C et D étaient une même machine ce qui garanti, vu la remarque précédente, qu'effectivement D ne reçoive pas le message HELLO émis par C.

==== Variations sur un même thème ====

Altérations des paquets HELLO envoyés à B: (on casse le draft AODV et on regarde comment se comporte KAODV)

* Le spoof de l'IP source dans l'en-tête IP ''est'' nécessaire pour que l'information "next hop" soit correcte dans la table de routage d'AODV.
* La destination ne doit pas être nécessairement un broadcast, on peut envoyer le message à un noeud bien précis uniquement.
* Bref seul compte le payload AODV (les 20 bytes de data) et l'adresse source du paquet.
* On peut mettre le champ IP SRC à 0, vu qu'il n'y a pas eu de message RREQ à l'origine de ce RREP, c'est l'IP DST qui est enregistrée dans la table AODV, destination pour laquelle une route est proposée. Le champ IP SRC n'est nécessaire que pour forwarder un message plus loin, ce qui nécessite un TTL>1 que nous n'avons pas dans ce cas-ci.
* je n'ai pas très bien compris l'usage du "sequence number" et plus spécifiquement dans un paquet HELLO, bien que cela ne semble pas très critique... Cela semble indiquer à AODV quelle information choisir s'il en reçoit 2 contradictoires de 2 sources différentes, il prendra celle de séquence la plus élevée.
* on peut jouer sur le Lifetime pour persister dans la table plus longtemps que les 3000ms par défaut des messages envoyés par KAODV mais à vérifier tout de même lorsque d'autres paquets non AODV sont émis et interceptés par AODV pour mise à jour de la table de routage...

Kernel AODV Spoof Hello - Revision history

PhilippeTeuwen at 00:06, 26 February 2008