Expert - Bloquer l'ARP spoofing niveau Firewall/IDS

[webseb]

Bonjour à tous,

Je ne vais pas revenir sur ce qu'est l'arp spoofing, mais j'aimerais avoir plusieurs avis sur comment s'en protéger.

En effet, détecter l'arp spoofing n'est pas très dur (broadcast arp, utilisation d'outils comme arpwatch etc...) mais l'empêcher niveau réseau est une autre affaire.

Quelque solutions existent déjà pour lutter contre ce phénomène :

- Faire de l'arp statique au niveau des machines (inenvisageable dans un réseau de grande taille).
- Utiliser des fonctionnalités offertes par certains commutateurs (exemple port security sur switch Cisco), bien que ça n'empêche pas l'arp cache poisoning, ca limite quand même quelques attaques (branchements clandestins ou usurpation mac). Le problème c'est que c'est lié à certains constructeurs en particulier.
- Préprocesseur Snort ARP et arpwatch : très bien mais ça ne fait que détecter (le fait de recevoir un mail n'empêchera en rien l'attaque).

Ma question est comment lutter efficacement contre l'arp spoofing au niveau d'une sonde Firewall/IDS placée à un endroit du réseau une fois que l'on a repéré la machine qui fait de l'arp spoofing?

Donc indépendamment du matériel actif utilisé et sans modifications sur les machines.

J'ai pensé à la solution d'isoler le traffic de la machine en question en retournant l'arp spoofing contre la machine qui lance l'attaque (avec un système de blacklist permettant d'éviter de bloquer les serveurs critiques). J'aimerai avoir des avis sur cette solution et surtout savoir si certains d'entre vous auraient une solution plus propre.

D'avance merci,

.webseb

[Walkyrie_II]

Je ne comprends pas bien ton problème.
Sur un réseau switcher avec un auto-apprentissage des adresse MAC par les commutateurs il n'est pas possible (sauf pour swith vulnérable au débordement de tampon) d'usurper une adresse mac une fois la première prise en compte. Donc tu ne peux pas répondre à un Bcast à la place d'une autre machine...

[Walkyrie_II]

Sinon reste ebtables, arptables
http://ebtables.sourceforge.net/
http://www.die.net/doc/linux/man/man8/arptables.8.html[/url]

[webseb]

Je suis d'accord, qu'avec des fonctionnalités de protection au niveau du switch (style port security), tu peux pas usurper une adresse mac au niveau du switch (j'ai cité ces fonctionnalité à titre d'exemple seulement, ca ne protège en rien de l'arp spoofing), mais au niveau du cache ARP des machines c'est différents.

Pour rappel, l'arp spoofing (ou arp cache poisoning, le terme n'était peut être pas exact, mais par abus de langage pour moi c'est la même chose) est une attaque qui vise à corrompre le cache arp des machines (et pas des switchs...). En gros pour écouter le traffic entre machine A et machine B (attaque Man In The Middle classique) tu envoie des paquets ARP reply avec l'adresse IP de B et ton addresse MAC à la machine A et tu route les paquets reçus vers la machine B avec l'IP de A et ton adresse MAC. A croit que t'es B et B crois que t'es A : A<--->attaquant<---->B.

L'auto-apprentissage, ou le codage en statique des adresses mac au niveau du switch ne sert ici strictement à rien, puisque qu'aucune adresse mac ne change au niveau du switch. Tu ne répond pas à un broadcast mais tu forge simplement des paquets ARP reply à destination des machines cibles (très facile à réaliser avec des outils comme Cain ou Dsniff). Maintenant il est également vrai qu'un broadcast ARP ne détectera pas l'arp poisoning (erreur dans mon premier message) et ne l'empêchera encore moins.

Des outils comme arpwatch détectent très bien ces changements en sniffant les ARP Reply (notamment si on utilise Cain qui broadcast ses modifications et donc sont directement repéré par arpwatch). En revanche, l'utilisation d'outils comme Dsniff(arpspoof) est très difficile à détecter (corruption unicast) et d'ailleur si certains ont des conseils quand à la détection de cet outil (ça c'est encore un autre problème -> http://forums.ixus.fr/viewtopic.php?p=240872#240872), je suis également preneur.

Je reviens donc sur la prévention une fois que l'on a détecté qu'une machine envoie des arp reply.

[webseb]

Sinon reste ebtables, arptables
http://ebtables.sourceforge.net/
http://www.die.net/doc/linux/man/man8/arptables.8.html[/url]

Encore pour précision, je voudrai empécher l'arp spoofing à l'échelle d'un réseau entier (et pas au niveau d'une machine, sinon oui là, pas de problème, plein de solutions existent).

Une sonde Firewall/IDS/IPS placcé à un endroit du réseau ne capture malheuresement pas tout le traffic (tous les postes connectés à un switch communiquent directement par l'intermédiaire du switch, et donc ne passent pas par la sonde, sauf pour aller sur le net ou sur un serveur de la DMZ). Rien n'empèche un petit malin sur son poste d'écouter le traffic de son administreur réseau pour récupérer ses mots de passent lorsqu'il se connecte en telnet à ses routeurs/switchs, ou encore d'écouter le traffic VoIP (RTP) entre son PDG et son chef voir même d'y injecter quelques insultes etc... Les menaces de l'arp spoofing sont multiples, difficiles à détecter et permettent de contourner bien des protections...

[zeuss14]

Je sais pas si ca pourrait t'aider mais tu pourrait faire des VLAN par adresse Mac et/ou par port du coup ca devient deja plus chaud de conecter une machine sur le réseau pour faire ce type d'ataque.

Sinon regarde peu etre du coté du 802.1X ....

[A.i.A]

Bonjour ,

1 . Personne n'a encore trouvé une solution contre l'arp spoofing ??

2 . Est ce qu'on peut contrer a l'aide de l'IDS SNORT , l'arp spoofing et l'arp flooding , si oui , comment ?


c'est ma première participation
Merci beacoup ,

A.i.A