Home arrow Linux arrow Linux Security arrow Penetration testing with ARP spoofing and Ettercap
Penetration testing with ARP spoofing and Ettercap Print E-mail
Written by Jason   
Feb 16, 2007 at 06:45 PM

How knowledgeable are the users on your network? Would they know if someone was trying to surreptitiously find out their login information, or capture sensitive information sent from their computer?

Would you? 


I wrote this article with the belief that if you are forewarned, you are forearmed; knowing what to expect on your internal network if you have a hacker is difficult even under ideal circumstances. Please keep in mind that the following article could wind you up in jail if you do it on a network that you don't have the right to do this on. Under no circumstances should you try this on a network that has any amount of important data on it without fully understanding what you are doing - ARP poisoning or other switch based redirection can wreak havoc on some hardware and software. You could easily do something illegal and unethical with this information (just like any information, really) so use good judgment. If you destroy your data and get arrested, you're the one to blame, not me. Do not take internally, One coupon per customer, etc. et. al.

What is Ettercap 

Ettercap (technically EttercapNG) is a nifty package that was developed with subterfuge in mind. It can be used to secretly gather usernames and passwords from unencrypted network traffic on the same local network, as well as some types of encrypted traffic by performing a SSL 'man in the middle' attack. This type of attack reroutes the victims network traffic through the attackers machine while picking out the 'good' parts - such as usernames, passwords, website information, etc.

One of the most common ways to use Ettercap is to use it with an ARP spoofing attack (more on this later), so covering this kind of attack and how to prevent it is what this article is about. Ettercap is considerably more than just a simple ARP spoofing package, so start with the man page for Ettercap if you'd like to learn about other uses for it.

Installing Ettercap

There are three ways to get and run Ettercap: download and compile the source, download a third party compiled binary, or download a Live CD distribution that has Ettercap already installed. Ettercap can be downloaded from here as source code to compile yourself. Or, you can look for a precompiled package from here. I wrote this article using SuSE 10.2 and I've ran the precompiled SuSE 9.x binary without problems as well as compiled it myself. I'd recommend trying to compile it yourself with the following directions, but if you simply can't get it working you can always try downloading a binary package. As a last resort you can always look for a Live CD distribution that contains Ettercap as well.

If you're going to try to compile Ettercap, the first thing to notice is the requirements. These are the most essential for the current version, 0.7.3:

libpcap >= 0.8.1
libnet >=
iptables (technically not required, but needed for this article)

The following are required for additional functionality. Don't shy away from having these installed before compiling Ettercap, the additional functionality can be very useful in the right situation:

openssl 0.9.7
ncurses >= 5.3
pkgconfig >= 0.15.0
Glib >= 2.4.x
Gtk+ >= 2.4.x
Atk >= 1.6.x
Pango >= 1.4.x

Many of these can be installed automatically with a good package manager such as yum or smart if you have a good selection of repositories. With all the right dependencies in place, compiling Ettercap should be very simple. The INSTALL file lists these commands, plus a few more. From a command prompt, run the following as root from the directory you've extracted the source code to:

make install

If all went as well, Ettercap should now be installed. Now, we just need to configure it (and your machine):

vi /etc/etter.conf
Toward the top of this file there is a line ec_uid = 65534, change this to ec_uid = 0

Now we need to uncomment two additional lines. Remove the # symbol from the front of each of these lines:
#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"

Now, save the file and exit with :wq
Type echo 1 > /proc/sys/net/ipv4/ip_forward
Disable your firewall. In SuSE this is done with Yast > Security and Users > Firewall > Disable Firewall
Enable IP forwarding on the network adapter. In SuSE this is done with Yast > Network Devices > Network Card > Select Your Network Adapter > Modify > Routing > Enable IP Forwarding.

All done! These commands worked on SuSE 10.2; but not all Linux distributions are created equally. If you can't seem to get Ettercap compiled and no precompiled binaries work for you, you can find Ettercap loaded on a few Live CD Linux distributions such as Aghesa or Backtrack.

Using Ettercap on yourself

As root:

ettercap -Tp

This will allow Ettercap to 'sniff' any traffic passing through your machine. Pull up a web browser and visit a secure website and see what happens! FTP to a server such as ftp.suse.com, Telnet to one of your servers, or check your POP3 email for more fun.

Using Ettercap on your test network

Once you have Ettercap installed and your system ready to go you just need a target on your test network. Never, never run this on your production network without full, written permission from your IT manager - you could go to jail! Last warning!

Let's say the machine you're running Ettercap on has an IP address of and the router on your network is - very common for gateway devices on small networks - and a target machine of From a command line as root:

ettercap -T -M arp:remote / /

This command executes an ARP spoofing attack. It fools the gateway and the target machine into thinking that the MAC address of each is the MAC address of the machine running Ettercap - thus making the Ettercap machine a secret relay between the two. All traffic should be routed correctly from one to the other through the Ettercap machine - even SSL (https://) traffic. Ettercap will generate a fake SSL1 certificate on the fly with information it finds in the real certificate; this will cause a popup on the target machine's web browser in most cases asking if they want to trust the certificate. In my experience most users will hit yes anyway.


SSL man in the middle attacks require the most complex setup for Ettercap. Several things need to be in place, otherwise all SSL requests by the target will time out. This is generally related to a misconfiguration on the machine running Ettercap with iptables or having a firewall turned on. The default kernel in some distributions do not forward packets by default; it's possible you might need to recompile your kernel with IP forwarding enabled.

Fighting back

Now that you've seen what a rogue system on your network can do using ARP spoofing, the next step is learning how to stop it, or at least mitigate the risk somewhat.

One of the most difficult aspects of defending against this type of attack is simply finding out that an attack is occurring. On the vast majority of networks no monitoring takes place at the data link layer where ARP resides (layer 2 in the OSI model), meaning a rogue machine could work indefinitely without being detected, silently gathering data for nefarious purposes.

Arpwatch is a package that keeps a database of MAC to IP address pairings and feeds this information to syslog; keeping a record like this is a very crucial step in determining how long an ARP spoofing attack has been going on and from what machine. Arpwatch is pretty simple to use and uses very little resources, so I recommend using it on just about any machine. If you're worried about the resulting log size, you can always forward the logs to a central syslog server; syslong-ng allows for quite a bit of flexibility in parsing and storing these logs. Combine this with the free Splunk server product and a robust, effective monitoring solution is born.

Using IPSec Authentication can provide some level of security as well against man in the middle attacks, in effect turning an ARP spoofing attack into a denial of service attack. Personally, my preference is to have a denial of service rather than allow sensitive data to be compromised, but it's an imperfect solution for other reasons, most of which are inherent to running IPSec Authentication to begin with - such as administration and proper support for legacy devices. 

Dividing your broadcast domains in your network up can limit the effectiveness of an ARP based attack. Traffic for a machine not on the same broadcast domain as the attacker cannot be redirected due to the nature of ARP; it's a broadcast protocol. Dividing your important servers into a separate network can provide a layer of security against this type of attack and follows good industry design standards.

One additional method of defending against this attack is to hardcode each IP address to each MAC address on vulnerable systems. Naturally, this has a high level of administrative overhead and can be cumbersome and fraught with problems in some situations. Implementing a solution such as this is only practical for a limited number of servers and devices in most cases, but is probably one of the more effective methods of actually stopping ARP spoofing attacks. 

In the end, ARP spoofing attacks are tricky to detect (mostly due to the fact that ARP normally works so well), but their effectiveness is limited to individual networks. Monitoring what's going on at layer 2 is crucial to detecting these types of attacks and is the best chance of stopping an attacker before they can cause damage.

Did I miss something? Let know what you think. 

Last Updated ( Feb 20, 2007 at 01:25 PM )
� http://www.roboguys.com, Mambo and Designed by Siteground