Ettercap : spoof arp pour bloquer (iptables) bittorent

[ReDnAxE]

Bonjour, je me trouve dans une situation ou quelqu'un de mon réseau local télécharge au point de ruiner la bande passante.

Je souhaite faire du spoof arp entre sa machine (192.168.1.118) et le routeur (192.168.1.1) (car pas d'autre solution ; il a accès à la config du routeur, bref)

Jusque là pas de problème.

Je nettoie ensuite mes tables iptables (police par défaut ACCEPT sur les 3 tables)

Mes questions sont les suivantes :
Les règles de filtrage, je dois bien les mettre dans la table filter, chaine FORWARD ?

Ensuite... je ne sais que bloquer les ports serveurs de bittorent (si j'ai bien compris le principe de cet outil) :
iptabes -A FORWARD -p tcp --dport 54816 -j DROP
iptabes -A FORWARD -p tcp --sport 54816 -j DROP

iptabes -A FORWARD -p udp --dport 54816 -j DROP
iptabes -A FORWARD -p udp --sport 54816 -j DROP

Mais ca n'empeche pas le téléchargement ....
Comment pourrais-je mettre en place les filtres pour empecher le téléchargement ? je regarde wireshark, j'ai l'impression que les ports changent tout le temps, que les adresses ip aussi...

[yop fr]

regarde si upnp est activé

[ReDnAxE]

J'arrive pas à trouver de doc sur upnp pour savoir exactement ce que c'est, en tout cas oui il est activé sur le routeur. (il est pas activé sur mon backtrack quand meme...?). En tout cas je souhaite trouver une solution sans entrer dans les réglages du routeur (ben oui, sinon pas besoin de MITM....)

J'ai réfléchi le problème autrement, avec la police par défaut DROP sur FORWARD. Je souhaite autoriser certains services uniquement ; ca marche pour le service http :

iptables -t filter -A FORWARD -s 192.168.1.0/24 -d 0.0.0.0/0 -p tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

(et pour le retour, je fais large :
iptables -t filter -A FORWARD -s 0.0.0.0/0 -d 192.168.1.0/24 -p all -j ACCEPT)

mais ca ne marche pas pour le service ftp :
iptables -t filter -A FORWARD -s 192.168.1.0/24 -d 0.0.0.0/0 -p tcp --dport 21 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

Pourtant, j'ai bien chargé les modules suivant :
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe iptables_nat
modprobe ip_nat_ftp
modprobe ip_nat_irc

(Lequel module ftp charger, les deux ou bien uniquement l'un des deux ?)

J'enregistre les paquets dropés dans les logs, voici effectivement la ligne d'une tentative de connection de données ftp en passif :
Nov 6 04:40:46 (none) kernel: NfForwardDropIN=eth0 OUT=eth0 SRC=192.168.1.118 DST=80.244.41.10 LEN=48 TOS=0x00 TTL=127 ID=28878 DF PROTO=TCP SPT=3274 DPT=43723 WINDOW=65535 RES=0x00 SYN URGP=0

[ReDnAxE]

Ok j'ai trouvé le problème, pour faire mes tests, je ne faisais pas de poisonning arp, je configurais juste comme passerelle la machine attaquante, et du coup les réponses ne repassaient pas par cette machine mais allait directement de la vraie passerelle vers la machine cible.

Je pense que j'ai répondu au problème que je me posais, et que la machine cible ne pourra désormais plus télécharger, j'ai juste à lui autoriser certains ports (80, 20, 21, 22, 23, 110, 443, ...)

[~LCF~]

Juste une petite remarque : ce genre de solutions ne sont pas pérennes. Elles seront très efficaces ponctuellement (quand on a besoin de débit et que quelqu'un utilise un client p2p par exemple) c'est certain.

Pour un contrôle constant (et plus propre, c'est à dire n'exploitant pas une faille d'un protocole, mais en utilisant le protocole lui-même), une bonne idée est de crée un PC/firewall/AP : tout le trafic passe sur ce PC AVANT d'atteindre la box. Certaines cartes WIFI supportent très bien le mode Master.

Dans ce cas, pas besoin d'entrer dans le routeur : le client gourmand en bande passante devra juste considérer que ton PC est l'AP. Pas besoin non plus d'exploiter une faille...

Sache tout de même que ce genre de méthode (MITM sur ton propre PC) n'est pas forcément une excellente idée. Si tu es en filaire, ça marchera très bien.

En wifi, je ne suis pas certain que ce soit si efficace dans un premier temps puisque tu stoppes le traffic UDP au niveau du PC, pas avant, c'est à dire que tu recevras tout le trafic tout de même (saturation de la bande passante du wifi). Même si tu décides de ne pas le router... Cette remarque est valable dans un sens comme dans l'autre.

Cependant, au bout d'un certain temps, le client ne recevant plus d'infos du serveur, et le serveur ne recevant plus d'infos du client, réduiront leur trafic. Tout cela pour dire qu'il ne faut, a priori, pas s'attendre à de grands résultats en quelques secondes avec un MITM comme celui-ci.

[ReDnAxE]

Tout à fait LCF.
La chose marche tout de même bien et l'effet est vraiment rapide. (Je ne suis pas en wifi).

Il y a cependant un comportement que je trouve bizzare, peut-être est-ce ettercap qui modifie le comportement initial d'un forward classique.
Voici deux fichiers ; syslog qui enregistre les paquets droppés de la chaine filter > forward, et debug qui enregistre les paquets acceptés dans la chaine filter > output.

Je retrouve les mêmes lignes dans syslog et dans debug, excepté l'ID (ip)... Pourtant, mon blocage de ports a l'air de fonctionner car la machine ne peut plus télécharger...


bt log # cat syslog | grep "SPT=26018 DPT=10633"
Nov 9 05:19:37 (none) kernel: NfForwardDropIN=eth0 OUT=eth0 SRC=192.168.1.118 DST=123.194.209.175 LEN=330 TOS=0x00 PREC=0x00 TTL=127 ID=2229 7 PROTO=UDP SPT=26018 DPT=10633 LEN=310


bt log # cat debug | grep "SPT=26018 DPT=10633"
Nov 9 05:19:37 (none) kernel: NfOutputAcceptIN= OUT=eth0 SRC=192.168.1.118 DST=123.194.209.175 LEN=330 TOS=0x00 PREC=0x00 TTL=128 ID=20764 PRO TO=UDP SPT=26018 DPT=10633 LEN=310



Bizzare quand même ?? Ou est-ce que j'aurais oublié une particularité du fonctionnement de Netfilter ? Qui dirait que les paquets forwardés passent par forward et ensuite par output..(je ne crois pas!) ?

[~LCF~]

Oui, effectivement, la chaîne forward n'est pas censée renvoyer les paquets vers output... (sachant que les deux n'ont peut-être (sans doute) rien à voir).

Ça c'est une question intéressante comme je n'en ai pas vue depuis longtemps !

Par contre, je suis crevé et je n'ai plus vraiment le temps, mais j'y jetterai un coup d'œil assez rapidement : c'est assez intriguant (et très stimulant !)...

D'ici là, bonne soirée.

EDIT: Je n'y crois pas à ettercap qui modifie le comportement de Netfilter. Je pense que c'est une mauvaise interprétation (de notre part) des logs... Mais vraiment rien ne me vient ce soir. J'y pense et je te dis si je trouve quelque chose.

[ReDnAxE]

Content de te stimuler LCF !!!!

Oui, en effet, non pas qu' ettercap modifie le comportement de Netfilter, mais qu'il récupère les paquets et les renvoie (ce qui voudrait dire qu'ils sont envoyés en double...?). En tout cas le but semblerait être que les paquets puissent être lus/modifiés par les différents plugins d'ettercap..?


Dès qu'on parle de drop dans la chaine forward ou output, des séries de lignes d'erreurs apparaissent dans Ettercap comme celle-ci :

SEND L3 ERROR: 40 byte packet (0800:06) destined to 209.85.229.156 was not forwarded (libnet_write_raw_ipv4(): -1 bytes written (Operation not permitted)
)

[ReDnAxE]

Alors la je commence a plus rien comprendre du tout!!
J'utilise désormais arpspoof (option -t sur les deux machines cibles). (L'une des machines cibles est un mac)
j'active ip_forward.
(En passant, avec arpspoof, plus aucun paquet passe par la chaine OUTPUT )

Lorsque je met comme police ACCEPT a forward, le mac peut ouvrir une page internet, mais lorsque je rentre ces règles, plus rien (sauf si je rajoute la règle light en avant dernière position, alors la page web s'affiche)


Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 192.168.1.0/24 192.168.1.0/24
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * * 192.168.1.0/24 0.0.0.0/0 tcp dpt:20 state NEW,RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.0/24 tcp spt:20 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 192.168.1.0/24 0.0.0.0/0 tcp dpt:21 state NEW,RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.0/24 tcp spt:21 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 192.168.1.0/24 0.0.0.0/0 tcp dpt:22 state NEW,RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.0/24 tcp spt:22 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 192.168.1.0/24 0.0.0.0/0 tcp dpt:23 state NEW,RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.0/24 tcp spt:23 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 192.168.1.0/24 0.0.0.0/0 tcp dpt:25 state NEW,RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.0/24 tcp spt:25 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 192.168.1.0/24 0.0.0.0/0 tcp dpt:53 state NEW,RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.0/24 tcp spt:53 state RELATED,ESTABLISHED
2 891 ACCEPT tcp -- * * 192.168.1.0/24 0.0.0.0/0 tcp dpt:80 state NEW,RELATED,ESTABLISHED //Ok, les requetes passent par là, normal
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.0/24 tcp spt:80 state RELATED,ESTABLISHED //Logiquement, les réponses http reviennent par ici non?????
0 0 ACCEPT tcp -- * * 192.168.1.0/24 0.0.0.0/0 tcp dpt:8080 state NEW,RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.0/24 tcp spt:8080 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 192.168.1.0/24 0.0.0.0/0 tcp dpt:443 state NEW,RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.0/24 tcp spt:443 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 192.168.1.0/24 0.0.0.0/0 tcp dpt:110 state NEW,RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.0/24 tcp spt:110 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.0/24 state NEW,RELATED,ESTABLISHED,UNTRACKED //Elles ne reviennent même pas par là !!!!
8 3570 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 //Apparement elles reviennent par là, et encore, je ne sais pas dans quel sens les requêtes vont
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `NfForwardDrop'


Je ne comprends pas.... du tout pourquoi mes règles ne marchent plus... -_- depuis que j'utilise plus Ettercap!!!! (avant, on voyait bien les requetes sur une ligne, et les réponses sur la ligne d'en dessous....)



EDIT : j'ai zoomé l'avant derniere règle par deux règles, en fait ce ne sont pas les retours qui arrivent, mais les allés :

0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.0/24
10 2341 ACCEPT tcp -- * * 192.168.1.0/24 0.0.0.0/0

Mais ou viennent les retours? Apparement le spoof arp ne fonctionne pas ? Si je n'ai pas les réponses http, les handshake (ESTABLISHED) ne sont plus à jours, et forcement, la connexion est bloquée.
pourtant je lance deux terminaux dans lesquels je lance :
arpspoof -t 192.168.1.111 192.168.1.1
arpspoof -t 192.168.1.1 192.168.1.111

Je précise également que dans la table arp de la machine mac (apple!) cible, la passerelle renvoie bien vers l'adresse mac de la machine attaquante... d'ou mon étonnement... j'ai du zappé un truc.. mais quoi

[~LCF~]

Ca m'étonne pour ettercap, mais après tout, ça ne semble pas débile du tout... Je n'ai pas encore le temps de tester ce genre de choses par moi-même... Peut-être demain, sinon ce week-end.

Par contre, juste une question (en attendant d'avoir plus de temps car cette méthode (filtrage d'un MITM) est géniale, c'est à se demander pourquoi je n'y ai pas songé avant quand j'avais besoin de bande passante : je ne faisais que pourrir le cache ARP des ordis qui bouffaient de la bande passante, pas très discret donc) : pourquoi, lors de ton MITM ne bloques-tu pas seulement le traffic udp en forward ? Ca semble plus simple non ? Pour résoudre ton problème initial (sans préciser les ports à filtrer : tu fais tout passer SAUF l'udp).


Bref, quand j'ai un peu plus de temps, promis, je teste ça !