Protection contre le arp poisoning
Résolu/Fermé
iswaren
Messages postés
77
Date d'inscription
mardi 21 janvier 2014
Statut
Membre
Dernière intervention
31 août 2015
-
31 août 2015 à 00:38
brupala Messages postés 109416 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 19 avril 2024 - 31 août 2015 à 19:15
brupala Messages postés 109416 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 19 avril 2024 - 31 août 2015 à 19:15
A voir également:
- Protection contre le arp poisoning
- Sentinel protection installer - Télécharger - Antivirus & Antimalwares
- Show arp - Forum Réseau
- Rav endpoint protection ✓ - Forum Virus
- Protection contre les virus et menaces ne s'affiche pas ✓ - Forum Antivirus
- Protection cellule excel - Guide
3 réponses
brupala
Messages postés
109416
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
19 avril 2024
13 618
31 août 2015 à 11:08
31 août 2015 à 11:08
Salut,
ta compréhension est fausse, car :
1/ il y a certainement un switch qui mémorise les adresses mac sur ses ports.
2/ si c'est sur FB, il y a une connexion TCP qui empêche de recevoir un paquet qui ne t'est pas destiné
3/ toujours sur FB, il ya certainement au dessus de TCP une couche TLS qui crypte les données et t'empêche de les lire si tu n'as pas négocié la clé.
4/ il faut échanger pas mal de paquets avant de commencer à envoyer un mot de passe, qui de toute façon ne circule pas sur le réseau, c'est seulement un code qui le représente.
5/ ARP poisoning n'est plus guère possible aujourd'hui car quasiment aucune machine n'accepte une réponse ARP qui n'est pas sollicitée via une demande, il faudrait donc être capable de répondre avant l'autre machine à une demande, ce qui n'est pas facile.
ta compréhension est fausse, car :
1/ il y a certainement un switch qui mémorise les adresses mac sur ses ports.
2/ si c'est sur FB, il y a une connexion TCP qui empêche de recevoir un paquet qui ne t'est pas destiné
3/ toujours sur FB, il ya certainement au dessus de TCP une couche TLS qui crypte les données et t'empêche de les lire si tu n'as pas négocié la clé.
4/ il faut échanger pas mal de paquets avant de commencer à envoyer un mot de passe, qui de toute façon ne circule pas sur le réseau, c'est seulement un code qui le représente.
5/ ARP poisoning n'est plus guère possible aujourd'hui car quasiment aucune machine n'accepte une réponse ARP qui n'est pas sollicitée via une demande, il faudrait donc être capable de répondre avant l'autre machine à une demande, ce qui n'est pas facile.
Salut,
Protection dans un réseau local ?
http://www.agnitum.com/outpost-firewall-pro.php
Monter le niveau de la détection d'attaques selon le besoin, ce pare feu est le meilleur au niveau des possibilités sur ce crêneau ( présence d'un NIDS ), et sur un PC.
Protection dans un réseau local ?
http://www.agnitum.com/outpost-firewall-pro.php
Monter le niveau de la détection d'attaques selon le besoin, ce pare feu est le meilleur au niveau des possibilités sur ce crêneau ( présence d'un NIDS ), et sur un PC.
iswaren
Messages postés
77
Date d'inscription
mardi 21 janvier 2014
Statut
Membre
Dernière intervention
31 août 2015
10
31 août 2015 à 14:53
31 août 2015 à 14:53
Oui je sais bien mais je ne cherche pas un moyen de protection là. Je demande une expliquation via les entrées statique!
Jodi
>
iswaren
Messages postés
77
Date d'inscription
mardi 21 janvier 2014
Statut
Membre
Dernière intervention
31 août 2015
31 août 2015 à 14:58
31 août 2015 à 14:58
Tu te débrouilles pour voir ça avec Wireshark, tu sauras si ça passe ou pas chez toi et pourquoi.
iswaren
Messages postés
77
Date d'inscription
mardi 21 janvier 2014
Statut
Membre
Dernière intervention
31 août 2015
10
31 août 2015 à 17:17
31 août 2015 à 17:17
Résolu
Lab avec wireshark
Communication entre Alice et Bob (entrée statique dans la table arp) : connexion sécurisée avec les deux machines. Aucun paquet n'est parvenu au MITM
Communication entre Bob et Facebook : Connexion à moitié sécurisé. Le paquet sortant a pour chemin < Bob - routeur - FB > . Le paquet entrant < FB - routeur - MITM - Bob > mais le paquet est crypté. Donc il faut le décrypté avec d'autre outils pour récupérer les infos que FB renvoie.
Donc tu as faux brupala, la connexion TCP n'empèche en rien un paquet d'aller vers le MITM. Et c'est logique vu que la table ARP du routeur (ou du SW comme tu veux) est comprompu. Néanmoins, le paquet est crypté et seul Bob peur le décrypté.
2eme point où tu as encore faux : ARP est un protocole dans lequel une machine lui fait totalement confiance. D'où le fait que le poisoning est facile s'il y a pas de protection minimum. Confirmé avec un expert cisco et pas wikipedia. Même si la machine ne fait pas de demande arp, il accèpte les réponse et les inscrit dans son cache. C'est la faille du protocole.
Lab avec wireshark
Communication entre Alice et Bob (entrée statique dans la table arp) : connexion sécurisée avec les deux machines. Aucun paquet n'est parvenu au MITM
Communication entre Bob et Facebook : Connexion à moitié sécurisé. Le paquet sortant a pour chemin < Bob - routeur - FB > . Le paquet entrant < FB - routeur - MITM - Bob > mais le paquet est crypté. Donc il faut le décrypté avec d'autre outils pour récupérer les infos que FB renvoie.
Donc tu as faux brupala, la connexion TCP n'empèche en rien un paquet d'aller vers le MITM. Et c'est logique vu que la table ARP du routeur (ou du SW comme tu veux) est comprompu. Néanmoins, le paquet est crypté et seul Bob peur le décrypté.
2eme point où tu as encore faux : ARP est un protocole dans lequel une machine lui fait totalement confiance. D'où le fait que le poisoning est facile s'il y a pas de protection minimum. Confirmé avec un expert cisco et pas wikipedia. Même si la machine ne fait pas de demande arp, il accèpte les réponse et les inscrit dans son cache. C'est la faille du protocole.
brupala
Messages postés
109416
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
19 avril 2024
13 618
Modifié par brupala le 31/08/2015 à 19:20
Modifié par brupala le 31/08/2015 à 19:20
Confirmé avec un expert cisco et pas wikipedia. Même si la machine ne fait pas de demande arp, il accèpte les réponse et les inscrit dans son cache. C'est la faille du protocole.
un expert houla ...
En fait ça ne fonctionne sur les OS actuels que si une entrée du cache existe déjà pour cette adresse, sinon, la réponse n'est pas prise en compte.
par contre,
une demande (request) genre je suis machin, qui a cette adresse ? fausse en unicast va effectivement créer une entrée fausse et ça c'est une faille.
Donc tu as faux brupala, la connexion TCP n'empèche en rien un paquet d'aller vers le MITM. Et c'est logique vu que la table ARP du routeur (ou du SW comme tu veux)
Le paquet arrive peut-etre, mais la session tcp ne continuera pas.
Les paquet syn et ack du départ ne sont pas cryptés, c'est plus tard que TLS se met en place, dans les couches applicatives, pas TCP.
un expert houla ...
En fait ça ne fonctionne sur les OS actuels que si une entrée du cache existe déjà pour cette adresse, sinon, la réponse n'est pas prise en compte.
par contre,
une demande (request) genre je suis machin, qui a cette adresse ? fausse en unicast va effectivement créer une entrée fausse et ça c'est une faille.
Donc tu as faux brupala, la connexion TCP n'empèche en rien un paquet d'aller vers le MITM. Et c'est logique vu que la table ARP du routeur (ou du SW comme tu veux)
Le paquet arrive peut-etre, mais la session tcp ne continuera pas.
Les paquet syn et ack du départ ne sont pas cryptés, c'est plus tard que TLS se met en place, dans les couches applicatives, pas TCP.
31 août 2015 à 14:17
Je l'ai fait avec un kali linux, un windows 7 sp1 à jour et un windows 2k8 R2 à jour également. ça m'a pris 4 lignes de commande et 5min pour empoisoner le cache des 2 machines à partir du kali.
Sans protection, et il y en as quasiment aucune car les admin n'ont pas forcément des cours de sécurité en france (oui moi j'en ai pas eu en tout cas dans ma licence pro), le arp poisoning est facile et accessible à M. Tout le monde.
Une des protections de mettre en place un outil qui dit aux machine de ne pas accepter des réponse arp non sollicitée comme tu l'as dit ou faire des entrées static. Mais j'aimerais mieux comprendre les entrées static afin de mieux évaluer son coût de mise en place et maintenance.
Quand tu dis dans ton 2/ : une connexion TCP qui empèche de recevoir un paquet qui ne t'es pas destiné, peux-tu développer? Je ne vois pas de quoi tu parles. Car dans le paquet revient, le dst est la src du paquet syn donc si la mac adresse a été modifé, la mac dst du paquet ack est la mac src du paquet syn. Où TCP intervient ? on parle de la couche 2 là.
31 août 2015 à 16:53
Qui ça ARP ?
Personne n'a jamais eu confiance dans ARP, tout le monde s'est toujours accommodé de son peu de fiabilité, mais il a été supprimé dans IPV6, sans que le système soit bien meilleur d'ailleurs.
Après, dans un réseau switché, comme quasi tous les réseaux maintenant, c'est plus difficile et ça ne change pas non plus le fait qu'une machine n'a pas à lire un paquet Ip qui ne lui est pas destiné (sauf si elle est un routeur).
Pour tcp, pareil,
La couche tcp n' a pas à accepter un ack syn d'une machine à laquelle elle n'a pas envoyé de syn,
je passe à TCP parce que c'est toi qui parle de mot de passe fessebouc.