Dans sa prose, babas666 (babas...@free.fr) nous ecrivait :
> Lu dans un thread un peu plus bas : > "Ettercap est un sniffer évolué permettant entre autre le > sniff sur réseau switché "
C'est tout simplement par qu'un switch n'est pas fait pour faire de la securite.
Le principe est l'ARP Poisoning. Quand un hote A veut communiquer avec un hote B sur ethernet, il commence par envoyer une requete ARP. Cette requete demande tout simplement l'adresse MAC correspondant a l'adresse IP de B. B repond que la MAC associee a l'IP est la sienne, et on peut commencer a s'envoyer des trames ethernet. Pour ne pas envoyer une requete ARP a chaque fois qu'on veut emettre une trame, on tient un cache ou on stocke les resolutions ARP deja faites. Il se trouve que ce cache se met aussi a jour dynamiquement simplement en regardant les reponses aux requetes ARP. Et c'est la qu'on agit.
Je suis l'hote C, le pirate, et je veut intercepter le trafic entre A et B. J'envoie a A un nombre de fausses reponses ARP disant que la MAC associee a l'IP de B est la mienne. Je fais la meme chose pour B, mais avec l'IP de A. Au bout de trois ou quatre emission, A et B mettent leur cache ARP a jour.
Lorsque A va vouloir envoyer un paquet a B, il va consulter sa table ARP pour envoyer la trame correspondante. Or, l'adresse MAC qui s'y trouve est la mienne : donc il m'envoit la trame. Et idem pour B.
A present, je route le traffic entre A et B. Je peux donc l'intercepter, le modifier, prendre la place d'un des deux hotes, etc...
Comme un switch fonctionne au niveau 2, il est _incapable_ de detecter ce type d'attaque, meme s'il possede une table port/MAC statique. Pour qu'il le detecte, il faut un switch plus etoffe qui est capable d'associe une IP a une adresse MAC et donc tenir une table port/MAC/IP. Cette attaque vise les hotes, mais on peut aussi attaquyer le switch. Dans le cas d'un switch tout simple, on peut meme sniffer en spoofant une adresse MAC, ou simplement en creant une MAC storm qui, sur certains equipements affoles cette attaque, entraine le passage en mode hub du switch.
Globalement, le seul moyen d'eviter cela est d'avoir un cache ARP statique.
-- J'aimerai savoir s'il est possible de monter un réseau ethernet SANS HUB. comme on le fait entre 2 machines (en croisant les fils), on en a environ une quinzaine... est-ce que quelqu'un sait comment faire ?? -+- in Guide du Neuneu Ethernet - Ether pas net, Hub lie moi-+-
Dans sa prose, Xavier Henner (eucl...@nerim.net.nospam) nous ecrivait :
>> Globalement, le seul moyen d'eviter cela est d'avoir un cache ARP >> statique. > ou alors un programme genre arpwatch qui va enregistrer tous les changements > de table ARP. > Des que qq'un s'amuse ca va envoyer un mail d'alerte.
Sauf que ca n'empeche rien. Ca te signale juste l'operation. Si je fais l'attaque a 4 heures du mat', je doute qu'il y ait grand monde pour recevoir le mail. Sans parler que je suis tout a fait en mesure d'operer le meme genre d'action sur le serveur de mail principal :)
-- L'usenet est un NG comme les autres , non ? C'est quoi ces règles à dix sous , là ? C'est ici qu'on se prend la tête ? -+- D23 in GNU - Le neuneu a dissous, et dissous c'est pas cher -+-
Le 19 Feb 2002 12:05:18 GMT, Cedric Blancher a écrit :
> Dans sa prose, Xavier Henner (eucl...@nerim.net.nospam) nous ecrivait : > >> Globalement, le seul moyen d'eviter cela est d'avoir un cache ARP > >> statique. > > ou alors un programme genre arpwatch qui va enregistrer tous les changements > > de table ARP. > > Des que qq'un s'amuse ca va envoyer un mail d'alerte.
> Sauf que ca n'empeche rien. Ca te signale juste l'operation. > Si je fais l'attaque a 4 heures du mat', je doute qu'il y ait grand > monde pour recevoir le mail. Sans parler que je suis tout a fait en > mesure d'operer le meme genre d'action sur le serveur de mail principal > :)
pas faux (enfin pour ce genre de probleme j'ai tendence a rediriger les mails vers un bipper ou un tel portable)
mais le snif sur un LAN c'est généralement une attaque interne. Donc prévenir le sysadmin et collecter les preuves peut servir rapidement a vir^H^H^Hrégler le problème.
Et je vois plutot ca comme un moyen de prévention : on fait la publicité du système bien fort par des courriers internes, ou en envoyant un mail a l'alias général pour demander qui a changé son adresse IP.
Ca refroidit généralement le warlord.
Dans le cas de l'attaque qui vient de l'extérieur par une machine compromise, on est prévenu plutot rapidement et on peut isoler la machine.
> Comme un switch fonctionne au niveau 2, il est _incapable_ de > detecter ce type d'attaque, meme s'il possede une table port/MAC > statique. Pour qu'il le detecte, il faut un switch plus etoffe qui > est capable d'associe une IP a une adresse MAC et donc tenir une > table port/MAC/IP. Cette attaque vise les hotes, mais on peut aussi > attaquyer le switch. Dans le cas d'un switch tout simple, on peut > meme sniffer en spoofant une adresse MAC, ou simplement en creant > une MAC storm qui, sur certains equipements affoles cette attaque, > entraine le passage en mode hub du switch.
> Globalement, le seul moyen d'eviter cela est d'avoir un cache ARP > statique.
Désolé, mais sur un switch tu peut associer un port physique a une adresse MAC, si la l'adresse MAC change, ben le port est désactivé.
Simple, rapide, efficace!!!
Donc ce faire passer pour un autre sur un switch n'est pas aussi facile que ça quand le switch est bien configurer (on retombe toujours sur la même chose finalement).
OoO En cette fin de matinée radieuse du mardi 19 février 2002, vers 11:41, Cedric Blancher <blanc...@cartel-securite.fr> disait:
> Je suis l'hote C, le pirate, et je veut intercepter le trafic entre A et > B. J'envoie a A un nombre de fausses reponses ARP disant que la MAC > associee a l'IP de B est la mienne. Je fais la meme chose pour B, mais > avec l'IP de A. Au bout de trois ou quatre emission, A et B mettent leur > cache ARP a jour.
Mais chacun ne va pas protester quand il va voir ta prise de pouvoir (en voyant passer ta trame ARP forgée prétendant que tu prends sa place) ? -- THE BOYS ROOM IS NOT A WATER PARK THE BOYS ROOM IS NOT A WATER PARK THE BOYS ROOM IS NOT A WATER PARK -+- Bart Simpson on chalkboard in episode 3F03
> Désolé, mais sur un switch tu peut associer un port physique a une > adresse MAC, si la l'adresse MAC change, ben le port est désactivé.
> Simple, rapide, efficace!!!
> Donc ce faire passer pour un autre sur un switch n'est pas aussi > facile que ça quand le switch est bien configurer (on retombe > toujours sur la même chose finalement).
En pratique ça devient rapidement ingérable si tu veux laisser un peu de liberté à des utilisateurs bricoleurs :-) donc ça dépend aussi du profil des utilisateurs.
Y'a aussi le problème de la saturation des tables de correspondance MAC adresses / Port qui transforme facilement en quelques secondes un switch en HUB pour les nouvelles machines non référencées dans la table du switch (en plus du problème de l'ARP Spoofing)... (c'est comme ça que réagissent les switches CISCO par exemple, certains switches plantent --> voir macof)
Sebastien Reister <s...@ffgolf.org> writes: > Désolé, mais sur un switch tu peut associer un port physique a une > adresse MAC, si la l'adresse MAC change, ben le port est désactivé.
> Simple, rapide, efficace!!!
> Donc ce faire passer pour un autre sur un switch n'est pas aussi > facile que ça quand le switch est bien configurer (on retombe > toujours sur la même chose finalement).
Non: ce que tu dis n'est valable que pour les switches *managables*.
Le switch "de base" ne permet pas du tout ce genre de configuration (d'ailleurs, le switch de base ne permet aucune configuration...).
Dans sa prose, Sebastien Reister (s...@ffgolf.org) nous ecrivait :
>> Globalement, le seul moyen d'eviter cela est d'avoir un cache ARP >> statique. > Désolé, mais sur un switch tu peut associer un port physique a une > adresse MAC, si la l'adresse MAC change, ben le port est désactivé.
Sauf que si tu lisais ce que je te racontes, tu aurais compris que quand on fait de l'ARP spoofing, on ne change pas d'adresse MAC. Ce qu'on change, c'est l'association MAC/IP au niveau du cache de la cible. Du point de vue du switch, rien n'a change, on ne l'a d'ailleurs meme pas attaque.
> Simple, rapide, efficace!!!
Pas dans ce cas la, je te fais la demo quand tu veux.
> Donc ce faire passer pour un autre sur un switch n'est pas aussi > facile que ça quand le switch est bien configurer (on retombe > toujours sur la même chose finalement).
Personnellement, pour un switch ne gerant pas les associations port/MAC/IP, je trouve ca trivial*, mais bon ;)
* test et approuve sur un 2924XL avec couples port/MAC en dur.
-- Halaud, enhoiré ! Le GCU passe encore mais le GNU, jamais. -+- BL in Guide du Neuneu Usenet : A l'infu de fon flein gré.-+-
Dans sa prose, Vincent Bernat (vincent.ber...@raysa.org) nous ecrivait :
> OoO En cette fin de matinée radieuse du mardi 19 février 2002, vers > 11:41, Cedric Blancher <blanc...@cartel-securite.fr> disait: >> Je suis l'hote C, le pirate, et je veut intercepter le trafic entre A et >> B. J'envoie a A un nombre de fausses reponses ARP disant que la MAC >> associee a l'IP de B est la mienne. Je fais la meme chose pour B, mais >> avec l'IP de A. Au bout de trois ou quatre emission, A et B mettent leur >> cache ARP a jour. > Mais chacun ne va pas protester quand il va voir ta prise de pouvoir > (en voyant passer ta trame ARP forgée prétendant que tu prends sa > place) ?
Mais non, parce que justement tu es sur un environnement switche, et c'est ca qui est beau : c'est ce qui etait sense t'empecher de sniffer qui empeche la veritable station de detecter le poisoning !
Alors que la requete ARP est envoye en broadcast ethernet, la reponse a cette requete est envoyee en unicast, puisqu'on sait a qui on repond. Donc, tes reponses ARP forgees sont envoyees en unicast a la cible (A par exemple). Donc, tout est switche, la machine que tu usurpes (B dans ce cas) ne recoit rien.
On dit "merci qui ?"... Merci le switch ! :))))
-- Halaud, enhoiré ! Le GCU passe encore mais le GNU, jamais. -+- BL in Guide du Neuneu Usenet : A l'infu de fon flein gré.-+-
>> Je suis l'hote C, le pirate, et je veut intercepter le trafic entre A et >> B. J'envoie a A un nombre de fausses reponses ARP disant que la MAC >> associee a l'IP de B est la mienne. Je fais la meme chose pour B, mais >> avec l'IP de A. Au bout de trois ou quatre emission, A et B mettent leur >> cache ARP a jour.
> Mais chacun ne va pas protester quand il va voir ta prise de pouvoir > (en voyant passer ta trame ARP forgée prétendant que tu prends sa > place) ?
Ben non, puisque le réseau est switché, il n'y a que ta victime qui reçoit tes paquets :-) De plus, je ne crois pas qu'une machine soit capable de remarquer qu'une autre machine essaye de s'approprier son adresse MAC. Faudrait éplucher un peu plus ARP.
-- Quelqu'un connait il la vitesse en mètres par seconde du chameau d'Egypte ? -+- JM in: Guide du Cabaliste Usenet - Bien configurer son chameau -+-
> >> Je suis l'hote C, le pirate, et je veut intercepter le trafic entre A et > >> B. J'envoie a A un nombre de fausses reponses ARP disant que la MAC > >> associee a l'IP de B est la mienne. Je fais la meme chose pour B, mais > >> avec l'IP de A. Au bout de trois ou quatre emission, A et B mettent leur > >> cache ARP a jour.
> > Mais chacun ne va pas protester quand il va voir ta prise de pouvoir > > (en voyant passer ta trame ARP forgée prétendant que tu prends sa > > place) ?
> Ben non, puisque le réseau est switché, il n'y a que ta victime qui > reçoit tes paquets :-) > De plus, je ne crois pas qu'une machine soit capable de remarquer qu'une > autre machine essaye de s'approprier son adresse MAC. Faudrait éplucher > un peu plus ARP.
bah si on sniffe les échanges ARP on peut voir l'attaque se dérouler d'ou la présence conseillée d'un arpwatch dans un réseau dont on n'est pas sur. Ca permet de voir très vite qui joue aux rigolos et de sévir.
> bah si on sniffe les échanges ARP on peut voir l'attaque se dérouler > d'ou la présence conseillée d'un arpwatch dans un réseau dont on n'est pas sur. > Ca permet de voir très vite qui joue aux rigolos et de sévir.
Oui. Mais dans ce cas il te faut un port du switch qui monitore tout le trafic (avec toutes les implications que ça peut avoir sur le dimensionnement dudit port :-)
-- Créer une hiérarchie supplementaire pour remedier à un problème (?) de dispersion est d'une logique digne des Shadocks. * BT in: Guide du Cabaliste Usenet - La Cabale vote oui (les Shadocks aussi) *
Le 20 Feb 2002 17:23:11 GMT, Daniel Polombo a écrit :
> Xavier Henner said :
> > bah si on sniffe les échanges ARP on peut voir l'attaque se dérouler > > d'ou la présence conseillée d'un arpwatch dans un réseau dont on n'est pas sur. > > Ca permet de voir très vite qui joue aux rigolos et de sévir.
> Oui. Mais dans ce cas il te faut un port du switch qui monitore tout le > trafic (avec toutes les implications que ça peut avoir sur le > dimensionnement dudit port :-)
ou mettre un arpwatch sur toutes les machines.
reste que la soltion completement secure reste de figer les tables arp des machines importantes. avec une commande globale pour réinitialiser quand on ajoute une machine
> reste que la soltion completement secure reste de figer les tables arp > des machines importantes.
Ces deux solutions présentent l'immense inconvénient de réclamer de la maintenance sur chaque machine. De plus, je ne suis pas convaincu que ça soit possible sur toutes les plate-formes (pas de noms, pas de noms :).
Je préfère personnellement les switchs capables de faire du verrouillage à la fois sur la MAC et l'IP : si sur un port donné tu n'as pas et la bonne MAC et la bonne IP, zou, au trou. C'est déjà plus délicat à bypasser, sans être aussi lourd à mettre en oeuvre.
-- Moi si je devais voter pour ce forum, je serais d'accord pour virer tous les abrutis!!! -+-DF in Guide du Neuneu Usenet - Ce neuneu s'autodétruira dans 1 mn -+-
<polo...@cartel-securite.fr> wrote: >Ces deux solutions présentent l'immense inconvénient de réclamer de la >maintenance sur chaque machine. De plus, je ne suis pas convaincu que ça >soit possible sur toutes les plate-formes (pas de noms, pas de noms :).
Ok, pas de noms .....
Y avait pas un problème sous NT qui faisait que même les entrées ARP qualifiées de statiques (-s) pouvaient être overwritées via le rézo ?
> Sauf que si tu lisais ce que je te racontes, tu aurais compris que > quand on fait de l'ARP spoofing, on ne change pas d'adresse MAC. Ce > qu'on change, c'est l'association MAC/IP au niveau du cache de la > cible. Du point de vue du switch, rien n'a change, on ne l'a > d'ailleurs meme pas attaque.
Soit j'ai lu en diagonale, j'aurais du me mefier!!! Mea Culpa
> > Simple, rapide, efficace!!!
> Pas dans ce cas la, je te fais la demo quand tu veux.
non, non c bon je te crois.
> > Donc ce faire passer pour un autre sur un switch n'est pas aussi > > facile que ça quand le switch est bien configurer (on retombe > > toujours sur la même chose finalement).
> Personnellement, pour un switch ne gerant pas les associations > port/MAC/IP, je trouve ca trivial*, mais bon ;)
Malgré tous mon assertion "La sécurité passe par une bonne configuration de tous les éléments du reseau." reste vrai.
> Globalement, le seul moyen d'eviter cela est d'avoir un cache ARP > statique.
Ou de dire au switch de limiter le nombre d'adresses MAC par port. Et de n'en mettre qu'une seule. Mieux, on peut même entrer l'@ MAC de ta machine et émettre une alarme en cas de changement et bloquer le port en même temps (un bête Cisco Catalyst 1924 permet la manip).
Cedric Blancher wrote: > Dans sa prose, Sebastien Reister (s...@ffgolf.org) nous ecrivait :
>>>Globalement, le seul moyen d'eviter cela est d'avoir un cache ARP >>>statique.
>>Désolé, mais sur un switch tu peut associer un port physique a une >>adresse MAC, si la l'adresse MAC change, ben le port est désactivé.
> Sauf que si tu lisais ce que je te racontes, tu aurais compris que quand > on fait de l'ARP spoofing, on ne change pas d'adresse MAC. Ce qu'on > change, c'est l'association MAC/IP au niveau du cache de la cible. Du > point de vue du switch, rien n'a change, on ne l'a d'ailleurs meme pas > attaque.
Et comment gère-tu le fait que la 1ère requète ARP sera vue en même temps par ta machine et la machine désignée ? Elle va en effet répondre probablement en premier. Est-ce que tous les OS réagissent de la même façon ? De plus, tiennent-ils compte des requètes reçues APRES en avoir reçue une autre ?
Dans sa prose, Bad Max (nounou...@netscape.net) nous ecrivait :
> Ou de dire au switch de limiter le nombre d'adresses MAC par port. Et > de n'en mettre qu'une seule. Mieux, on peut même entrer l'@ MAC de ta > machine et émettre une alarme en cas de changement et bloquer le port > en même temps (un bête Cisco Catalyst 1924 permet la manip).
C'est moi ou j'ai l'impression que personne ne me lit ? Quand tu fais de l'ARP spoofing, tu ne changes pas ton adresse MAC. Donc tu peux n'avoir qu'une adresse MAC par port, ca marchera aussi !...
> Et comment gère-tu le fait que la 1ère requète ARP sera vue en même > temps par ta machine et la machine désignée ? Elle va en effet répondre > probablement en premier. Est-ce que tous les OS réagissent de la même > façon ? De plus, tiennent-ils compte des requètes reçues APRES en avoir > reçue une autre ?
Decidemment, va falloir apprendre a lire. On ne repond pas a des requetes, on envoie des _reponses_ sans qu'il y ait eu de requete pour que la cible, voyant ces trames, modifie d'elle-meme son cache ARP. Il n'y a aucune requete de la part de personne. De toute maniere, une fois l'operation effectuee, l'hote cible n'emet plus de requete ARP pour l'IP qu'on a ARP spoofee, puisqu'elle est en cache, et B ne verra plus de reponse ARP pour l'IP spoofee, puisque ces reponses sont en unicast.
Donc on revise un peu ARP, et puis des papiers sur la question :
Pour proteger un OS contre ca, soit on lui colle une table ARP statique, en renseignant par exemple le fichier /etc/ethers, soit on force une expiration rapide des entrees, comme sous Solaris :
-- Le dino, c'est celui qui comprend un message qu'il ne lit pas. Le neuneu, c'est celui qui ne comprend pas un message qu'il lit. -+-GF in Guide du Neuneu Usenet - Et c'est ainsi qu'Allah est grand-+-
Cedric Blancher <blanc...@cartel-securite.fr> writes: > C'est moi ou j'ai l'impression que personne ne me lit ?
Si, ceux qui connaissent deja :-)
> Pour proteger un OS contre ca, soit on lui colle une table ARP statique, > en renseignant par exemple le fichier /etc/ethers, soit on force une > expiration rapide des entrees, comme sous Solaris :
> Pour coller un expiration a 1 min au lieu de 20.
Meme pas: il suffit d'emmettre cette reponse ARP a intervalle regulier pour pouvoir continuer a sniffer tranquille....
Alors bon, tu peux toujours ramener l'expiration a quelques secondes, mais ca risque d'avoir de facheuses consequences sur les performances du reseau, et ca ne *garantit* toujours pas qu'on ne peut pas sniffer du tout (mais on a beaucoup moins de chances d'intercepter l'ensemble du traffic).
Seule la table ARP statique est donc efficace contre ce genre de sniff...
> On ne repond pas a des requetes, on envoie des _reponses_ sans qu'il y > ait eu de requete pour que la cible, voyant ces trames, modifie > d'elle-meme son cache ARP. Il n'y a aucune requete de la part de > personne. De toute maniere, une fois l'operation effectuee, l'hote cible > n'emet plus de requete ARP pour l'IP qu'on a ARP spoofee, puisqu'elle > est en cache, et B ne verra plus de reponse ARP pour l'IP spoofee, > puisque ces reponses sont en unicast.
Je ne suis pas tout à fait d'accord ... en tout cas pour un noyau Linux 2.4.0 : je l'explique et je le prouve ;-)
Attention : Tout ce qui suit est testé et approuvé (par mes soins) avec un noyau linux 2.4.0 : je ne sais pas ce qu'il en est pour les autres versions du noyau et pour les autres OS.
Le problème : La mise à jour du cache ne se fait pas tant qu'il n'y a pas eu de "question" ARP. En revanche, une fois qu'une réponse a été émise, le cache accepte plusieurs réponses, et c'est la dernière reçue qui l'emporte (je ne sais pas quel est le "temps d'acceptation" de la réponse).
Exemple : Les protagonistes sont : - charly : machine depuis laquelle je lance l'attaque (MAC=00:C0:FD:02:06:FF) - bosley : machine dont je veux usurper l'adresse MAC (MAC=00:C0:4F:9C:0E:3E IP=192.168.10.66) - kelly : machine cible sur laquelle je veux usurper l'adresse MAC de bosley (IP=192.168.24.103 et dont on se fout de l'adresse MAC)
Je lance le spoof et tout se passe maintenant sur kelly :
** Sur la cible (kelly - 192.168.24.103) : [root@kelly /root]# arp Address HWtype HWaddress Flags Mask Iface charly ether 00:C0:FD:02:06:FF C eth0
kelly n'a fait encore aucune requête ARP => le cache de kelly ne contient pas bosley. On lance une commande qui nécessite une "question" ARP :
[root@kelly /root]# traceroute bosley traceroute to bosley (192.168.10.66), 30 hops max, 38 byte packets 1 bosley (192.168.10.66) 2.349 ms 0.429 ms 0.414 ms
Puis on regarde le cache ARP : [root@kelly /root]# arp Address HWtype HWaddress Flags Mask Iface bosley ether 00:C0:4F:9C:0E:3E C eth0 charly ether 00:C0:FD:02:06:FF C eth0
Tiens, il a la bonne adresse :( Mais après qq secondes, on regarde à nouveau : [root@kelly /root]# arp Address HWtype HWaddress Flags Mask Iface bosley ether 00:C0:FD:02:06:FF C eth0 charly ether 00:C0:FD:02:06:FF C eth0
Bingo !
Je ne sais pas si ce comportement est normal ou pas, mais je constate juste ce qui se passe.
Je suppose que le décalage entre les 2 caches résulte d'une course et que dans un premier temps, c'est bosley qui gagne, mais qu'ensuite, la cache est mis à jour par les réponses de charly (si qq'un peut confirmer, infirmer ou préciser ;)
Je serai très curieux de savoir comment ça se passe avec d'autres OS et versions du noyau. Donc si qq'un a le matériel, le temps et le courage de faire les tests, merci de me tenir informé ;)
-- Frédéric RAYNAL http://minimum.inria.fr/~raynal <pub> Rédacteur en chef de M.I.S.C. - Multi-Systems & Internet Security Cookbook </pub>
