Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
Can you elaborate on where you were performing the ARP poisoning and how it relates to your Internet connection? –  schroeder Sep 12 '12 at 15:13
    
I am testing several things I will post my progress on the end of the week I don't have much time now :( –  jkarr Sep 12 '12 at 19:09
    
Did you tried ping? test . Did you tried remove arp cache entries from victim computer and trying then. –  Saladin Mar 9 '13 at 15:34

6 Answers 6

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.

share|improve this answer
5  
IIRC it's also possible to ARP poison only one machine (i.e. don't respond to all ARP queries, just those from a specific host). That method is much less likely to cause disruption.. –  Rоry McCune Sep 2 '12 at 12:47
    
yes I am aware of that you saying, but the think is that I don't stop application that's handling the man in the middle so I am wondering what is happening... –  jkarr Sep 2 '12 at 13:42
1  
@jkarr It might be that your tool isn't working properly. Try analysing your network with a tool like Wireshark, to see what ARP packets are being broadcast. –  Polynomial Sep 2 '12 at 14:46
    
@Polynomial seems a good idea I will make the test and post back the results –  jkarr Sep 2 '12 at 16:25

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
+1 Nice work:) btw you can refer to me as 'asadz' next time –  Saladin Mar 9 '13 at 22:44

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).

share|improve this answer
    
This doesn't really answer the question. –  Adnan Mar 9 '13 at 19:59

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.