Why is ARP poisoning killing all network activity?

Question

Using ettercap and ARP poisoning, I was able to eavesdrop on other connections, but suddenly I was unable to make any connection to the Internet. To restore Internet connectivity, I had to restart my router. (I have tested this on 3 different routers: sagem, linksys and huawei.)

Am I doing something wrong or is there a safety mechanism that kills all network activity?

Answer 1

ARP spoofing usually works by fooling all the clients into thinking that you're the router, by faking the ARP responses that translate IP addresses to MAC addresses. When clients receive the ARP response, they remember the MAC that was associated with the IP.

Once you stop the application that's handling the man-in-the-middle part of the operation, the clients keep sending to your MAC address, instead of the router's. Since you're no longer handling such packets, the traffic is blackholed and the whole network goes down. Resetting the router causes it to send an ARP broadcast (e.g. "Hi, I'm 192.168.1.1 at 12:34:56:78:90:AB") along with a DHCP broadcast, allowing clients to re-sync with the real router.

It may be possible for your ARP poisoning software to send out an ARP broadcast when it closes, with the real MAC address of the router, in order to prevent this. This may be a bug, or it may just not be implemented yet.

Answer 2

If you only have one network interface card, you may be blackholing everything. You would need one nic (or virtual nic) to connect to the clients and act as the spoofed router/switch and one to forward traffic on to the switch. I know that ettercap can handle this for MiTM'd traffic, but don't recall if it also provides your machine with internet access.

When you exit from ettercap, it should re-establish internet connectivity by sending out the correct arp packets to the currently MiTM'd victims, cutting you out of the middle and re-establishing their internet connectivity.

Make sure that when you MiTM you aren't MiTM'ing the router for yourself as well.

Answer 3

Your question seems to indicate that you were running Ettercap on the Internet ... ISPs often have ARP spoofing detection and would cut you off when they saw your malicious activity.

Answer 4

In my experience, HTTP traffic (from an android client) is forwarded correctly on mountain lion running ettercap 0.7.5.3, but HTTPS breaks down. SSLStrip also failed (so far, for me).

Answer 5

It has happened to me as well. I would put my bet on redirection or forwarding problems. What is required is that on iptables you must configure to sent it to destination. Right mow it just turned into blackhole for you.

"sudo iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 666" ### iptables will forward port 80 to our box, running sslstrip on port 666.

Ref sslstrip

I hope the above commands help you configuring your IPtables.

Answer 6

Another addition to the forwarding/routing points people have made, if you are running a Linux based OS, you will need to turn on IP forwarding, otherwise the kernel will just drop any packets destined for an IP address that isn't attached to any local interface.

You can turn on ip_forwarding by running (as root);

echo "1" > /proc/sys/net/ipv4/ip_forward

And likewise turn it off again with;

echo "0" > /proc/sys/net/ipv4/ip_forward

This will have immediate effect, and does not require a reboot.