I've never used it but you may want to look into using scapy's routing table. This will let you route packets differently than your system.
conf.route
I'm creating an ARP poisoning MITM program with scapy, and I've run into a snag. I can't properly forward a tcp connection from the victim machine to the gateway, and back.
Basically my code looks like this:
This should work, but my machine sends a shitload of RST packets to the destination IP.Code:def routep(self, packet): if packet.haslayer(scapy.IP): ether = packet.getlayer(scapy.Ether) ether.src = self.ni.mac # host-to-gateway if packet[scapy.IP].src == self.victimIP: ether.dst = self.gatewayMAC # gateway-to-host elif packet[scapy.IP].dst == self.victimIP: ether.dst = self.victimMAC else: return # fix checksums, lengths, and ACKs by deleting the original values del(packet[scapy.IP].chksum) if packet.haslayer(scapy.UDP): del(packet[scapy.UDP].chksum) del(packet[scapy.UDP].len) elif packet.haslayer(scapy.TCP): del(packet[scapy.TCP].chksum) del(packet[scapy.TCP].ack) # do the evil deed :) scapy.sendp(packet, iface=self.ni.name) scapy.sniff(filter='(src %s) or (dst %s)' % (self.victimIP, self.victimIP), prn=lambda x: self.routep(x))
hxxp://trac.secdev.org/scapy/wiki/FAQ
Here it says,
Is there seriously NO way of doing this without configuring my OS's firewall? Other programs like ettercap get along just fine, so obviously there's some way that they do it. Are there any better methods of forwarding TCP traffic?The kernel is not aware of what Scapy is doing behind his back. If Scapy sends a SYN, the target replies with a SYN-ACK and your kernel sees it, it will reply with a RST. To prevent this, use local firewall rules (e.g. NetFilter for Linux). Scapy does not mind about local firewalls.
I've never used it but you may want to look into using scapy's routing table. This will let you route packets differently than your system.
conf.route
I don't see how that would work...the packet sent by the victim is already destined to 192.168.0.1. How would I route this to the _real_ 192.168.0.1 gateway, without manually changing the packet's destination MAC address?
I didn't look that closely at your code. I just assumed you had already done the arp poisoning and were looking for a way to route the packets to their correct destination after you had received them.
I'm sorry, maybe I didn't explain myself clearly enough. I have already done ARP poisoning on the target machine.
I ARP poison, say, 192.168.0.4, and tell that machine that the gateway, 192.168.0.1, is located at my attacking machine's MAC address. When my attacking machine receives 192.168.0.4's packets, it needs to send them to the real 192.168.0.1. I have no idea how to do this without manually changing the destination MAC address on each packet.
have you tried just setting the ip_forward bit? It works with other arp poisoning techniques.
Try setting eth0 to 0.0.0.0 and send out arp replies using 192.168.1.125 as the MITM.Is there seriously NO way of doing this without configuring my OS's firewall? Other programs like ettercap get along just fine, so obviously there's some way that they do it. Are there any better methods of forwarding TCP traffic?
When your machine recive a packet with 192.168.1.125, replie.
I think the honey project uses this way in its arp program.
Firstly, you must set ipforwarding.
One of your interfaces should be set to monitor mode and maybe the other to promiscuous.
You need to be aware that switches do not repeat/resend all traffic like a hub would do.
From what I understand you wish to reroute packets through your machine then on to the gateway. This is monitoring and as such should not involve recrafting the packets so you should not be concerned whether they are udp or tcp. You will need to flood the hub or switch and hand-out the mac address of your daemon as your gateway ip, then when each packet is captured and analysed it is forwarded to the gateway. You will need to pump occasionally to keep the arp tables correct for your purpose. Yes, you will need to capture packets assigned to the mac of the original gateway and of course change the mac in the header from your analysis machine to that of the gateway.
The above is trivial really, but the problem with python is that it is so slow. You will drop so many packets that the system is unmanageable. For the adequate collection of a reasonable number of packets you should use 'C' after your concept in python is proved.
Lux sit