ARP Empoisonnement et port en avant
Supposons ces hypothèses:
Routeur Adresse IP: 192.168.1.1
Routeur Mac Adresse: 00: 00: 00: 00: 00:
Mon adresse IP: 192.168.1.2
Mon adresse MAC: 00: 00: 00: 00: 00: 01
Victim IP Adresse: 192.168.1.
Victime Mac Adresse: 00: 00: 00: 00: 00:
Maintenant, si j'effectue une attaque d'empoisonnement ARP en utilisant Ettercap entre le routeur et la victime, si la victime veut envoyer un paquet à l'hôte externe, c'est ce qui se produirait:
La victime envoie un paquet avec ((( selon les affichages de Wireshark ):
Source IP: 192.168.1.3
Source Mac: 00: 00: 00: 00: 03
Destination: IP 'DEST'. Où 'Dest' est une IP externe comme '47 .32.1.6 '
Destination Mac: 00: 00: 00: 00: 01
((( car le paquet doit être livré à un hôte externe, il devrait être livré pour la première fois au routeur dont l'adresse MAC du point de vue de la victime est '00: 00: 00: 00: 00 : 01 '
Le routeur reçoit ce paquet et parce que le Mac me dirige (comme l'attaquant), il transmet le paquet à mon interface.
Maintenant, Ettercap obtient le paquet et reconnaît l'IP source comme IP de la victime (qui est "192.168.1.3") et la destination IP comme le routeur (deuxième victime), puis envoie ce paquet pour transférer le paquet à un hôte réel et permettre le streaming:
Source IP: 192.168.1.3
[.____] Source Mac: 00: 00: 00: 00: 00: 01
Destination IP: Dest
Destination Mac: 00: 00: 00: 00: 00
Ce processus a lieu pour chaque paquet recevant de la victime à Ettercap, mais si j'utilise le transfert de port par des règles IPTABLES, il semble que le paquet reçu à ma machine de la victime soit envoyé au routeur deux fois, car:
Ettercap reçoit le paquet et aussi loin que de la victime, ETTERCAP en avant au routeur.
Le système d'exploitation fournit le paquet à l'application de course locale qui écoute sur le port prédéfini. Par exemple, si j'utilise la commande ci-dessous:
iPTABL -T NAT -A PREROUTING -P TCP --Destination-Port 80 -J Redirection --To-Port 8080
ensuite, tout port de ciblage de paquets 80 est livré à l'application locale à l'écoute de 8080, puis l'application peut envoyer le paquet à l'hôte externe. (Par exemple, si c'est un proxy)
Mais surprenant cela ne se produira pas. En fait, ce qui se passe n'appartient que l'étape 2. Le paquet est livré à l'application locale et traite à venir.
Je pense que c'est parce que le système d'exploitation change l'adresse de la "adresse IP" de la réception de paquets à notre adresse IP d'interface, de sorte que lorsqueTERCAP attire le paquet et détecte que l'adresse IP de destination est l'adresse de notre propre ordinateur, elle ignore le paquet. Mais Wireshark affiche l'adresse IP correcte, pas le changé. Certains experts peuvent-ils expliquer ce qui se passe exactement ici?
Partie 1: Explication générique, inutile de lire si vous avez lu la question.
Le premier (comment arrive le paquet arrivé à l'attaquant:
La victime envoie un paquet avec source IP '192.168.1.3' et source Mac '00: 00: 00: 00: 00: 03 'à destination IP' Dest 'et destination Mac '00: 00: 00: 00: 01' . Où 'DEST' est une IP externe comme '47 .32.1.6 'Le routeur reçoit le paquet et parce que le Mac me dirige (comme l'attaquant), il transmet le paquet à mon interface.
La victime envoie un paquet avec une source IP de source '192.168.1.3' et Source Mac '00: 00: 00: 00: 00: 03 'à la destination IP '47 .32.1.6'. La victime ne peut pas trouver un itinéraire direct vers cette adresse (comme il n'est pas dans son sous-réseau), il envoie donc le paquet via la route par défaut, à '192.168.1.1' (c'est-à-dire à la passerelle par défaut, le routeur dans ce cas). Cependant, comme nous sommes sur Ethernet, la victime a besoin d'une adresse MAC pour envoyer le paquet. Vous mentionnez que le routeur a une adresse MAC: 00h00: 00: 00: 00: 00 ', mais l'attaquant a empoisonné la table ARP de la victime. Au lieu de l'entrée
192.168.1.1 00:00:00:00:00:00
la victime a l'entrée suivante dans sa table ARP:
192.168.1.1 00:00:00:00:00:01
(Vous pouvez vérifier cela en ouvrant une ligne de commande sur le PC de la victime et en exécutant la commande 'ARP -A' avant et après avoir démarré Ettercap).
Cela signifie que, chaque fois que la victime tente d'envoyer un paquet au routeur OR au réseau externe, ce paquet arrivera à l'attaquant jusqu'à ce que vous "réagira" la victime.
la seconde (comment le paquet arrive-t-il à sa vraie destination) :
Maintenant, Ettercap obtient le paquet et reconnaît l'IP source comme IP de la victime (qui est "192.168.1.3") et la destination IP comme le routeur (deuxième victime), puis envoie ce paquet pour transférer le paquet à un hôte réel et permettre le streaming:
Avant que l'empoisonnement ne commence, l'attaquant s'assure que sa table ARP contient les entrées correctes, comme si:
192.168.1.1 00:00:00:00:00:00 (the router)
192.168.1.3 00:00:00:00:00:02 (the victim)
Maintenant, dans la première section, nous nous sommes arrêtés au point où le paquet externe est arrivé au PC de l'attaquant, mais bien sûr, nous devons nous assurer que le paquet atteint sa "vraie" destination. Sinon, la victime n'aurait jamais une réelle réponse et le remarquerait donc assez rapidement que quelque chose est désactivé. Par conséquent, l'attaquant souhaite transférer le paquet à sa destination réelle: la passerelle par défaut (le routeur). Cela est possible, car l'attaquant connaît la vraie adresse MAC du routeur. Il reçoit en fait le paquet suivant de la victime:
Source IP: 192.168.1.3
[.____] Source Mac: 00: 00: 00: 00: 03
Destination IP: 47.32.1.6
Destination Mac: 00: 00: 00: 00: 00: 01
[.____] Le fait que l'adresse IP de destination soit traduite à l'adresse MAC de l'attaquant, est que la victime recherchera l'adresse IP de destination dans sa table de routage (itinéraire) et constate qu'il devrait envoyer ce paquet à la passerelle par défaut. Il envoie donc une demande d'ARP (ou regarde dans sa table ARP, ARP -A) et des avis que l'adresse MAC doit être envoyée au paquet est '00: 00: 00: 00: 01 '
Ce qui est important ici, c'est le fait que l'attaquant voit qu'il s'agit d'un paquet qui n'est en fait pas destiné à lui. Un paquet qui aurait été destiné à lui ressemblerait à ceci:
Source IP: 192.168.1.3
[.____] Source Mac: 00: 00: 00: 00: 03
Destination IP: 192.168.1.2
Destination Mac: 00: 00: 00: 00: 00: 01
Donc, chaque fois que l'attaquant reçoit un paquet, il vérifiera la source de la source et la destination, puis de l'envoyer à l'aide de son tableau ARP non poisoné, dans ce cas à 200h00: 00: 00: 00: 00 '(le routeur).
Partie 2: Résumé de la question posée
Au début, la question n'était pas complètement claire pour moi. Cependant, après que CS l'a expliqué plus attentivement dans le chat, la question revient à ceci: dans une configuration, où EtterCap est active et une application personnalisée sur le port 8080 transfère activement le trafic (à la victime) et où le transfert de port Est actif pour rediriger le trafic entrant sur le port 80 à Port 8080 (l'application personnalisée), pourquoi est-ce que ces paquets (celle prévue à l'origine pour le port 80) n'arriver qu'une seule fois?
On pourrait penser que ce qui suit se produirait: - Le paquet se trouve sur le port 80, destiné à la victime, mais redirigé vers l'attaquant à cause d'une attaque d'empoisonnement ARP - IPTABLE redirige ce paquet de Port 8080 - Ettercap en avant le paquet à la victime. - l'application personnalisée, qui est explicitement construite pour des paquets de transfert, transmet également le paquet à la victime.
Cependant, la victime reçoit le paquet qu'une seule fois. Pourquoi?
Partie 3: La réponse finale
Ettercap ne transmettra que le trafic qui présente les caractéristiques suivantes:
- l'adresse MAC DEST MAC du paquet est la même de l'adresse MAC de l'attaquant
- la propriété intellectuelle est non la même chose que l'adresse IP de l'attaquant
Maintenant, le problème est que, en utilisant la commande iptables Redirect, ce qui suit se produit:
- le port de destination est modifié (de 80 à 8080 dans ce cas particulier)
- l'adresse IP de destination est modifiée par l'adresse IP principale de l'appareil sur lequel IPTables est en cours d'exécution.
- comme il s'agit d'une règle préservée, le ci-dessus arrive avant que le paquet n'atteint etercap
C'est le "changement IP de destination" qui répond à la question pourquoi le paquet n'est pas transféré deux fois. Imaginez le paquet suivant, destiné à un serveur Web externe en provenance de la victime:
Source IP: 192.168.1.3
[.____] Source Mac: 00: 00: 00: 00: 03
Destination IP: 47.32.1.66:8
Destination Mac: 00: 00: 00: 00: 00: 01
Si ce paquet devait arriver à Ettercap, la condition de transfert aurait été remplie: le Mac de destination du paquet est l'attaquant, mais l'adresse IP de destination n'est pas.
Maintenant, ce paquet n'arrive pas sous cette forme, la commande iptables Redirection la transforme en ce qui suit:
Source IP: 192.168.1.3
[.____] Source Mac: 00: 00: 00: 00: 03
Destination IP: 192.168.1.2:808
Destination Mac: 00: 00: 00: 00: 00: 01
Cela le fait, car le 192.168.1.2 est l'adresse IP principale de l'appareil sur lequel la commande redirection a lieu. Ainsi, ce paquet sera ignoré par Ettercap.
Partie 4: perspicacité finale
Maintenant, ce qui précède est en fait la même chose qui se produit au cas où vous activez la dissection SSL. Pour activer la dissection SSL, les lignes suivantes doivent être non motivées dans eter.conf:
redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
Comme vous pouvez le remarquer, il s'agit presque exactement de la même commande que la commande iptables mentionnée dans la question. Par conséquent, il en va de même: Ettercap ne transfère pas les paquets entrant sur le port 443. Ce qui se passe est le suivant:
- Le trafic de la victime est conclu, c'est censé aller sur un serveur HTTPS
- Parce qu'il est redirigé par IPTABLES, ETTERCAP ne sera plus transmise (comme l'adresse IP de destination est modifiée). Cela signifie que tout le trafic SSL reste sur le PC de l'attaquant.
- Ettercap crée ensuite un faux serveur, avec un faux certificat. Il commence à communiquer avec le vrai serveur SSL pour fournir HTML/JS, mais le client parle directement à Ettercap. Les paquets ne sont plus transférés.
C'est la même chose que dans le cas expliqué dans la question, à l'exception du fait que le dissecteur SSL ne transfère pas la circulation, alors que l'application créée par le TS est toujours.