Security of TCP/IP Address Resolution Protocol (ARP)

• Introduction
• ARP Cache
• Typical Operations on ARP Cache
• Security Issues
  • ARP Spoofing
  • MAC Flooding
  • MAC Duplicating
• Most important commands
• Microsoft arp utility

Introduction

The ARP protocol was defined in RFC 826 , written by David Plummer in 1982.  The ARP protocol is a broadcast protocol: it receives a destination IP address and sends out a broadcast request for all machines to see. The request asks the question:

If you are IP address N, please respond with your Ethernet (MAC) address.

Each host on the network monitors the network for these requests, when it's address is requested it sends a arp reply. The arp reply specifies the 48 bit Ethernet address to use for that IP address.

The ARP functions between the Internet and Network Interface layers of the TCP/IP model:

• TCP/IP Layers
  • Application Layer
  • Transport Layer
  • Internet Layer
    <----------------------------------------- ARP
  • Network Interface Layer

The necessary for ARP arise from the fact that in IP v4 packet header there is insufficient space to store MAC address along with the host part of the IP address (IPX and IPv6 can do that; that means that for those protocols there is generally less need for protocols like ARP although it still can serve MAC addresses to them, if necessary).

Therefore in order for two hosts to communicate, the logical IPv4 address must be resolved to the physical address of the network adapter card (MAC address). This is done by ARP. The idea is somewhat similar to DNS (in this case IP serves as pseudo DNS name that is resolved to MAC address).

The main problem with arp is that this a very old protocol created in 1982 and naturally it was created without any regards for security. 

ARP is necessary because  the sending host must complete the contents of the target address field in the Ethernet frame. The Ethernet frame must include the source and destination MAC addresses:

• Destination Ethernet Address. Provided via ARP
• SourceEthernet Address. The source Ethernet address is retrieved from the kernel which obtains it from nonvolatile random access memory (NVRAM) on boot. 
• TypeData
• Cyclic Redundancy Check

There can be two cases of MAC address resolution:

• If the final destination (receiving system) of the message being sent is on the same LAN as the sending system, only one MAC address resolution is required. This makes ARP somewhat similar to DNS: like in DNS address can be cashed or you need to get it somehow by sending a request.
• If, on the other hand, the final destination of the message is on a different LAN, multiple address resolutions will be required, one for each hop through a router until the final destination is reached. 

ARP is a broadcast protocol that works strictly within local network segment (does not cross the router boundary). If the final destination (receiving system) of the message being sent is on the same LAN as the sending system, only one ARP address resolution is required. If the final destination is on a different network, an address resolution might be required on each network that the message traverses on the path to its final destination.

For example, assume that the  system alpha must communicate with the system beta and it does not know the system beta MAC address.

1. In order to determine the MAC address of the system  the system alpha  sends an ARP request to the local subnet  using  the Ethernet broadcast address (ff:ff:ff:ff:ff:ff). The ARP request includes the IP address of the system beta. 
2. The broadcast is seen by all systems on the segment including, says,  beta and gamma.
3. The gamma and beta recognize that the ARP request contains the IP address and MAC address of the alpha and add this information to their ARP tables, if it is not already present. This type of entry is known as an unsolicited entry because the information was not explicitly requested.
4. The system beta identifies its own IP address in the ARP request and sends an ARP reply to the  system alpha. The ARP response includes the Ethernet address of the  system beta, and it is sent using the unicast Ethernet address of the system alpha.
5. The system alpha receives the ARP reply and stores the information about beta in its ARP table. This type of entry is a solicited entry because the system alpha requested this information

It would be silly to continually send an ARP request broadcast each time a host needs to find the physical address of another host it accesses often. For this reason, all implementations of TCP/IP include an ARP cache to hold IP address to MAC address mappings.

ARP Cache

ARP responses are cached in the ARP table to have the information available if it is required again in the near future. The ARP table, cached in memory, stores requested (solicited)  Ethernet addresses for up to 20 minutes. This table is read each time a destination Ethernet address is required to prepare an Ethernet frame for transmission. If an Ethernet address does not appear in the ARP table, an ARP request is sent. A host that replies to an ARP request also updates its ARP table with the IP and Ethernet addresses of the requesting host. There are two major types of entries in the cache:

• solicited entries are those where an Ethernet address was specifically asked for by a host,
• unsolicited entries are a result of storing information about a host that was performing an ARP request.
• static entries (discussed later, must be added manually using arp -scommand)
  • published entries -- a special type of static entries for which the host answers ARP entries on behave of another host.

In Solaris you need to use the command:

ndd /dev/ip ip_ire_arp_interval

to display the length of time that ARP entries are cached. The default is 1200000 microseconds (20 min).  That means that Solaris cache  solicited ARP entries for 20 minutes.

Unsolicited ARP entries cache for only 5 minutes.  Use the command:

ndd /dev/ip arp_cleanup_interval

If the entry has not been used for 15 minutes, it is deleted from the cache if the cache is at maximum capacity. If the cache is at maximum capacity and a new entry comes in, the first found entry will be yanked and replaced with the new entry.

In Solaris ARP cache parameters are stored in PROTOCOL.INI. The parameter, arptblsize, under the [tcp_xif] section controls the size of the ARP cache. The default is (tcpconnections*2) + 6. The range is 6 to 512 entries.

Typical Operations on ARP Cache

There are seven major operation that you can perform with arp cache:

1. You can examine all entries in the ARP table with the command:

   # arp -a

2. You can examine a specific ARP table entry with the command:

   # arp hostname

3. You can also add a static (until reboot) ARP table entry using the command:

   # arp -s hostname ethernet_address

4. You can populate an ARP table manually in situations in which the destination device cannot respond to ARP requests.  To add a published ARP table entry, perform the command:

   # arp -s hostname ethernet_address 
   		pub

5. You can create so called "published" ARP entry when you want a host to answer an ARP request on behalf of another host. This is a useful option for heterogeneous environments and some SLIP or PPP configurations in which some hosts cannot respond to ARP requests for themselves.
    
6. To add ARP entries from a file, perform the command:

   # arp -f filename

   Entries in the file should be in the form:

   hostname ethernet_address [pub]

7. To delete an ARP table entry, perform the command:

   # arp -d hostname

   where hostname is the name of the host or its decimal-dot notated IP address.

Security Issues

A switched network does not lend itself to sniffing as easily as a non-switched network. It does not broadcast most frames. But the development of switched networks was driven by the need for more bandwidth, not for the need of more secure networks. Still it is much more secure that non-switched network and there is no reason those days to use anything but switched networks. Although sniffing is more difficult, it is not impossible and several methods are available to sniff switched networks:

• ARP Spoofing. One of the basic operations of the Ethernet protocol revolves around ARP (Address Resolution Protocol) requests and replies. In general, when Node A wants to communicate with Node C on the network, it sends an ARP request. Node C will send an ARP reply which will include the MAC address. Even in a switched environment, this initial ARP request is sent in a broadcast manner. It is possible for Node B to craft and send an unsolicited, fake ARP reply to Node A. This fake ARP reply will specify that Node B has the MAC address of Node C. Node A will unwittingly send the traffic to Node B since it professes to have the intended MAC address. There are tools that care cable of doing this automatically sending fake ARP replies to classes of machines (i.e., NFS servers, HTTP servers, etc). One such tool is dsniff5 and it works well to sniff for specific types of traffic. Other tools listen for the general ARP request and send the fake ARP reply at that time. The parasite4 program falls into this category and it serves well to sniff the entire network. For this type of attack to work, we need the ability to forward on the frames we receive to their intended host. This is most commonly achieved through some type of IP forwarding, either at the kernel or application level.
• MAC Flooding. Since switches are responsible for setting up the virtual circuits from one node to another, they must keep a translation table that tracks which addresses (specifically, which MAC addresses) are on which physical port. The amount of memory for this translation table is limited. This fact sometimes allows the switch to be exploited by flooding the translation table. Primitive switches, not knowing how to handle the excess data, will 'fail open'. That is, it will revert to a hub and will broadcast all network frames to all ports. At this point generic network sniffers will work.
• MAC Duplicating. It's not difficult to imagine that, since all frames on the network are routed based on their MAC address, that the ability to impersonate another host would work to our advantage. That's just what MAC duplicating does. You reconfigure Node B to have the same MAC address as the machine whose traffic you're trying to sniff. This differs from ARP Spoofing because, in ARP Spoofing, we are 'confusing' the host by poisoning it's ARP cache. In a MAC Duplicating attack, we actually confuse the switch itself into thinking two ports have the same MAC address. Since the data will be forwarded to both ports, no IP forwarding is necessary.

There are several methods to protect again these attacks. Some of these methods are applicable to both the non-switched and switched environments. Some advanced switches has built-in protection from flooding. One solution is so called Sticky ARP like in Cisco 7600 Series Router

Sticky ARP prevents MAC address spoofing by ensuring that ARP entries (IP address, MAC address, and source VLAN) do not get overridden. The router maintains ARP entries in order to forward traffic to end devices or other routers. ARP entries are usually updated periodically or modified when ARP broadcasts are received. During an attack, ARP broadcasts are sent using a spoofed MAC address (with a legitimate IP address) so that the router learns the legitimate IP address with the spoofed MAC address and begins to forward traffic to that MAC address. With sticky ARP enabled, the router learns the ARP entries and does not accept modifications received through ARP broadcasts.

If you attempt to override the sticky ARP configuration, you will receive an error message. For a complete description of the system error messages, refer to the Cisco 7600 Series Router Cisco IOS System Message Guide at this URL:

http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/software/122sx/msggd/index.htm

Most important commands

The ARP table, cached in memory, stores requested Ethernet addresses for up to 20 minutes. If an Ethernet address does not appear in the ARP table, an ARP request is sent. Solicited ARP entries cache for 20 minutes, while unsolicited ARP entries cache for 5 minutes.

Most important commands

• arp -a -- views cache
• arp hostname   -- examines a specific ARP table entry
• arp -s hostname ethernet_address  -- adds a static (until reboot) ARP table entry
• arp -s hostname ethernet_address pub -- adds a published ARP table entry
• arp -f filename -- adds ARP entries from a file. Entries in the file should be in the form:
                     hostname ethernet_address [pub]
• arp -d hostname -- deletes an ARP table entry

Microsoft arp utility

Displays and modifies the IP-to-Physical address translation tables used by
address resolution protocol (ARP).

ARP -s inet_addr eth_addr [if_addr]
ARP -d inet_addr [if_addr]
ARP -a [inet_addr] [-N if_addr] 

• -a Displays current ARP entries by interrogating the current protocol data. If inet_addris specified, the IP and Physical addresses for only the specified computer are displayed. If more than one network interface uses ARP, entries for each ARP table are displayed.
  
• -g Same as -a.
• inet_addr Specifies an internet address.
• -N if_addr Displays the ARP entries for the network interface specified by if_addr.
• -d Deletes the host specified by inet_addr. inet_addr may be wildcarded with * to delete all hosts.
• -s Adds the host and associates the Internet address inet_addr with the Physical address eth_addr. The Physical address is given as 6 hexadecimal bytes separated by hyphens. The entry is permanent.
• eth_addr Specifies a physical address.
• if_addrIf present, this specifies the Internet address of the interface whose address translation table should be modified. If not present, the first applicable interface will be used.

arp -s 157.55.85.212 00-aa-00-62-c6-09	# Adds a static entry.
arp -a  # Displays the entire arp table.
arp -a  157.55.85.212  # Displays	the arp table entry for 157.55.85.212

NEWS CONTENTS

• 20061115 : Security Reference Guide MAC Filtering ( Security Reference Guide MAC Filtering, Nov 15, 2006 )
• 20050316 : Protection Against Arp Poisoning... ( Protection Against Arp Poisoning..., Mar 16 2005 )
• 20050316 : Silky_report ( Silky_report, )
• 20050316 : Exploit-Dev Archives Re ARP silliness w- Cisco 675 ( Exploit-Dev Archives Re ARP silliness w- Cisco 675, )
• 20050316 : ITworld.com - ARP networking tricks by Hal Stern Unix Insider 5/1/97
  ( ITworld.com - ARP networking tricks, )
• 20050316 : Linux.com Ping ICMP vs. ARP ( Linux.com Ping ICMP vs. ARP, )
• 20050316 : www.delmar.edu/Courses/ITNW1325/sem1/notes/lessons16-19.html ( www.delmar.edu/Courses/ITNW1325/sem1/notes/lessons16-19.html, )
• 20050316 : http://www.cs.sunysb.edu/~cse533/asgn4/asgn4.html ( http://www.cs.sunysb.edu/~cse533/asgn4/asgn4.html, )
• 20050316 : www.cisco.com/univercd/cc/td/doc/product/software/ssr83/rpc_r/48383.htm ( www.cisco.com/univercd/cc/td/doc/product/software/ssr83/rpc_r/48383.htm, )
• 20050316 : Protection Against Arp Poisoning... ( Protection Against Arp Poisoning..., Mar 16 2005 )
• 20050316 : www.leastprivilege.com - ARP Spoofing and XP SP2 ( www.leastprivilege.com - ARP Spoofing and XP SP2, )
• 20050316 : OptimumPath Secure Wireless Router ( OptimumPath Secure Wireless Router, )
• 20050316 : What to do against ARP-Poisoning? ( suse-security )
• 20050316 : Security Basics: Re: ARP Poisoning ( )
• 200102 : Spoof an IPv4 ARP Response " Musings ( Spoof an IPv4 ARP Response " Musings, )

Old News ;-)

[Nov 15, 2006] Security Reference Guide MAC Filtering

By default, every device on a wireless network has a unique address that's used to distinguish one wireless network interface card (WNIC) from another. This address is called the Media Access Control (MAC) address. In theory, since every WNIC has been pre-assigned a unique MAC address by the hardware vendor, an access point can be set up to only allow a pre-selected list of WNICs to connect. For example, the Linksys WAP11 includes a MAC filtering option in its software that allows an administrator to define who can connect to the WLAN by listing all the allowed MAC addresses. Once you have the MAC address of all the connecting WNICs, you can set up MAC filtering and enable it accordingly. This will stop many connection attempts made by unauthorized addresses. However, while in theory this is an excellent way to stop hackers from accessing your WLAN, there's a serious flaw in MAC filtering: MAC addresses can be spoofed (faked) by changing WNIC settings. For example, the Dell TrueMobile includes software that allows a hacker to alter his MAC address to any address he chooses. Thus, this option is about as useful as trying to keep people from accessing a chat room by restricting chat handle names. To bypass such a restriction, a person only has to change his or her name. Why would a software/hardware vendor want to allow a user to change a MAC address? Having the power to adjust a MAC address can provide a network administrator with more tools to keep control over the network. However, this increased power gives just as much control to an attacker. This is one example of how the ancient power struggle between user needs and security often plays right into an attacker's hands. Regardless, if MAC filtering is an option, you should implement it on your WLAN. Just as with enabling WEP, MAC filtering does require a modicum of sniffing and network expertise. Thus, it can also serve as an intellectual barrier to most of the potential intruders of your wireless network. Note that if your WLAN supports more than 100 users, managing the MAC control list could be a time-consuming chore.

[Mar 16 2005] Protection Against Arp Poisoning...

Mar 16 2005, 12:46 PMBeen playing alot with Cain and Abel recently and after realizing how powerful this tool is for sniffing traffic I want to now focus on counter measures against an attack this tool can perform - ARP poisoning. So can anyone recommend the best tools / techniques to protect against this?

EDIT: Just found this is already been covered on GovSec in the past. Im currently reading this paper that was recommended: http://www.cs.sjsu.edu/faculty/stamp/stude...ilky_report.pdf

However, i would like to hear from peoples experience on protecting against ARP poisoning and tools they have used.

Thanks

SyS49152

Mar 16 2005, 02:36 PM quite simple .. check the mac address of the most juicy host in your subnet (i.e. gateway , domain controller) then arp -a on your pc .. if there are differences you are poisoned ..
kbnetMar 16 2005, 02:56 PMCould do with a tool watching in real time. Just been reading the dsniff manual, l0pht's antisniff is mentioned so going to give that a try in a bit. Mar 16 2005, 03:12 PMThere are good tools like Arpwatch around . One of the ways is to enter static mac address entries so ur computer doesnt broadcast arp request but still other routers can be poisoned and u are still in half water . Use outpost firewall it has a plugin to block mac address so u can block all those unneeded hosts also sygate keeps a good watch on arp . But still arp is very much exploitable . U can kick anyone out of network no matter what they use . There are techniques to stop like Port security on switches ,etc.

Btw did u note with cain u can sniff only hashes of yahoo mail and no plaintext on lan even if u arent using secure login . Gmail sends plain text HOTMAIL sends plain text out and most others do . But yahoo hashes b4r sending maybe md5 i think . Only thing i like bat yahoo belgther

Mar 16 2005, 03:29 PM

static ARP tables can solve the solution of ARP Poisoning, thus disabling ARP protocol which prevents ARP Poisoning, too. The packets can be blocked by personal & router firewalls. Fancy, but possible... SyS49152

Mar 16 2005, 03:44 PM

Terminal ..
about yahoo you are right the pass is double MD5 hashed plus a challenge that changes
at any new connection .. kbnet

Mar 16 2005, 03:51 PM

Yeah, ive noticed most sites send passwords out in plain text. Been catching quite alot of traffic from the lan (its used by another 3 people) and noticed a few sites will send out MD5 hash. If i want to get an account from a user I just get them to run a script which steals key3.db and signons.txt. Suppose if i had the MD5 rainbow tables it would make life easier. Pro21

Mar 17 2005, 05:45 PM

QUOTE(belgther @ Mar 16 2005, 03:12 PM)

static ARP tables can solve the solution of ARP Poisoning, thus disabling ARP protocol which prevents ARP Poisoning, too. The packets can be blocked by personal & router firewalls. Fancy, but possible...

Yes but if you have a windows network, it s noticed with arp-sk it is possible to modify static ARP tables.

I think the best solution is to use ssl or vpn or anything like that to secure data from the network. And it s the easier solution than filter all MAC adress. It use more ressources I think ... skydance

Jul 11 2005, 10:27 PM

im usign XArp to detect ARP poisoning attacks: hxxp://www.chrismc.de/developing/xarp/ Warlord_David

Jul 12 2005, 04:56 AM

you can also spoof your address to hide where the attacks are coming from. packet

Jul 13 2005, 12:38 AM

Static ARP tables are great on all the devices you can control easily like routers and firewalls but getting them out to all clients and keeping them up to date can be a challenge. So hardware changes can be a much bigger deal when you need to replace that interface card.

If you don't hit the clients then dsnif for C&A can fool clients into thinking they are the gateway still and get lots of juicy info. I wonder if there is a way to do this with DHCP, send out the default GW and the MAC of that GW. But the GW is not the only thing worth protecting all servers and resources would be nice to protect too.

BTW, arpwatch is great for keeping an eye on this but when someone does start futzing it become almost too noisy with e-mails and log messages, you have to dial down the settings to make sure it doesn't flood out too much crap.

--PG

nolimit

Jul 13 2005, 01:11 AM

a fine tuned IDS system is probably your best route pita

Jul 13 2005, 02:55 AM

if u use ipsec in the network, all connections will be encrypted so even if you poison u will see nothing.

but this will solve the probleme of a man in the middle that is waiting for things like passwords in clear text but i'm not sure this will also help for the smart spoofing attack.

but maybe anyone had test this before?

packet

Jul 13 2005, 03:14 AM

But use IPSEC everywhere in the network? All clients to all servers? I know MS was trying something like that but I know they weren't ready to actually turn on encryption, just tunnels at this point.

But IPSEC could still be disrupted in any case as you could redirect traffic through you, and if any new man in the middle attacks come out then you would be sitting in the right place.

--PG

mmkhan

Jul 13 2005, 08:04 AM

QUOTE(Warlord_David @ Jul 12 2005, 09:56 AM)

you can also spoof your address to hide where the attacks are coming from.

then i think u will create a DOS on the network.

myth

Jul 13 2005, 03:41 PM

All of the above

Also, changing the network topology will reduce the effectiveness.... Ie, when designing the network, if its feasible, adding more subnets... That's a VERY basic way of saying it, but the basic idea is if you subnet the LAN more, then theres less static arps that would need to be applied and reduce the amount of IDS systems on the network...

Remember security is like an onion, placing an IDS there is just pointless if its on its own, because you can just ARP poison that IDS server in a way to 'isolate' it.. Using IPSec etc is kind of OK, but theres methods of faking certificates on weak authentication schemes. Placing Static ARPs is kind of OK but you need to apply them to every computer - so put them in login scripts. Using a correct type of IDS - ie Snort INLINE to actively monitor and kill connections is another method that should ALSO be applied in extreme circumstances...

So, Static ARPs + Correct use and location of network IDS's (Snort / Checkmate) + Static ARPs via login scripts to keep up-to-date + Subnetting the lans more (even via VLANs) + *Considering the use of IPv6 and other* + CORRECT Encryption of the protocols will allow even arp poisoned traffic to become useless

Those 6 methods would stop even the most dedicated hacker from using that method - so they might just go buy Key Katcher / Key Ghost and use that method instead...

* Dont quote me on that

Silky_report ARP Cache Poisoning Prevention and Detection. Silky Manwani.

CS 298 Project. 1. San Jose State University. ARP Cache Poisoning Detection and Prevention ...

Exploit-Dev Archives Re ARP silliness w- Cisco 675

Trevor Schroeder wrote:

> On Tue, 28 Sep 1999, Mikael Olsson wrote:

> > The ARP RFC states that when a host receives an ARP
> > query for itself, it should enter the sender's
> > address tuple into its ARP table so as to refrain
> > from having to query for information that it has
> > already, in effect, received.

> Just because the RFC states it, does not make it gospel. As much as I am
> in favor of RFC compliant behaviour, sometimes it's necessary to bend them
> as circumstances change. Not accepting ARPs any time from any body might
> be an acceptable change. It's not something that breaks the operation of
> the protocol.

The main reason I pointed this out is that this is what people do
in general; hence, it is usually real easy to spoof an ARP, even
though there's a race condition protection in place for the
responses.
(vuln-dev, remember :-)

However, when you don't have an entry for that host, you have
to make a decision:
1. Accept the address
2. Query for the address and see if you get multiple responses

It is often the case the you do NOT have the ARP entry for
a specific host; either due to reboot of either unit or due
to no communication between the units for some time.

(Yeah yeah the reboot problem is not such a great problem
with linux hosts and cisco routers, I know. Too bad a lot of
people have a lot less stable (a-hem) OSes running.)

> > [Requerying addresses every time you get a question]
> That's icky.

But it's the only protection you'll ever have if you don't already
have an entry.

> > 1. Add a central system having a master list
> > of MAC/IP tuples, which sends responses signed

> This is a really Bad Idea [tm]. You should consider long and hard before
> you resort to a central coordinator (and point of failure). That's the
> whole point behind having a distributed algorithm such as ARP.

I think I pointed out in my original post that these ideas were
"far from finished concepts" or something like that.
I just threw them out to give people some rough ideas that could
be used for further ideas, rather than for having them stomped at.

I know this isn't very practical. I maybe should have pointed
it out more feriouciosly.

> Besides, how are we going to know the ARP server's MAC address?

> > by an asymmetric cipher function. (Certificate)

> Now this is the correct approach but in the wrong context. The proper
> solution is IPsec's authentication headers. Let layer 2 play games if you
> want, but your attacker is going to have a hard time getting the AH right.

A-ha! Who was the first? The chicken or the egg?
You can't have IPSec work if your layer 2 doesn't work.
IPSec prevents sniffing and impersonation (using both AH and ESP as
you pointed out later on), but it does NOT prevent DoSing the
poor bastards with wild ARP spoofing.

> > 3. When you receive a changed MAC address, query
> > for the IP again and see what responses you receive
> > in, say, 1 second. If any of the responses match
>
> This is sort of what Linux does. Not strictly RFC compliant, but close
> enough for government work. (actually it checks the old MAC to see if it
> still claims the IP address being queried)

Here is where it gets interesting, things like these can be implemented
without totally rewriting the ARP protocol.

I have to wonder though, when you say "checks the old MAC to see if
it still claims the IP", do you mean that it sends out a directed ARP
to the old MAC, asking for the IP? Or does it broadcast?

In either case, I believe there are at least five ways that this
algorithm could be defeated (NOTE: A careful coder can protect
against 1 and 2)

1. Intruder races for the response, which says "No MAC Addr". This
is compliant with RFC 1868, "UNARP". The response basically has
HWAddrLen=0.
2. Intruder races for the response, which says that the hw addr for
the IP is the hw addr of the intruder.

Again, no flames for 1 and 2, these would only be a problem
if the coder screwed up. (But they DO screw up >:] )

3. Intruder floods the network of either host to the point where
either the query to the old host or the response from it gets
blocked. Remember that the intruder doesn't have to flood the
network for very long, and that this attack doesn't have to
work the first time.
A half-ass protection scheme would be to keep resending the
queries to the old host for a very long time.
I can see that kind of behaviour leading to serious stress
syndromes if an intruder starts trying to spoof a lot of ARPs.
4. Crash the original host, or make it consume lots and lots of CPU
power for a while. This way, it won't respond to the safety query.
5. Crash the original host and wait for the ARP entry pointing
to it to die from itself. This could be circumvented
if all ARP entries never timed out. Again, this might lead
to really nasty overload situations; sooner or later
one would probably have to start throwing ARP entries away
to preserve memory. This is especially the case in a
10.0.0.0/8 flat switched network.

Also, a real problem with these "sticky" ARPs is that once an
intruder gets hold of an IP address, it'll actually work
to his/her advantage.

*phew*
I suppose I could think of a few more if I really put my
mind to it.

--
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 ÖRNSKÖLDSVIK
Phone: +46-(0)660-105 50           Fax: +46-(0)660-122 50
WWW: http://www.enternet.se        E-mail: mikael.olssonenternet.se

ITworld.com - ARP networking tricks by Hal Stern Unix Insider 5/1/97

In March we introduced the Address Resolution Protocol (ARP), a half-brother to the TCP/IP stack that maps the logical IP address space into the real world of Ethernet hardware addresses. We didn't venture very far away from the safe confines of a local area network and some simple troubleshooting, which is fine for introducing the relationships of ARP to IP and various network broadcast activities, but it doesn't describe the real real world very well. If you're reading this, you've encountered a byzantine complex of hosts, routers, desktops, and networks that will lay claim to some measure of high availability, redundancy and well-ordered connectedness. To keep the packets flowing from one end to the other, no matter what secret packet vacuum networks you encounter on the way, you'll need to play games with IP addresses or MAC addresses and fool clients' ARP requests into believing your temporary version of network reality -- however cobbled together it might be.

This month we're going to complicate our simple explanation of ARP with a closer look at stupid networking tricks, starting with the interactions between the ARP family of protocols and the boot process. We'll toss some routers into the fray, and look at ways of sending packets to IP networks that aren't quite where the routers think they are, and finally we'll show you how to run multiple IP networks on the same physical network, a necessary strategy for most networking transition and migration plans. We'll sprinkle hints and pointers through this conclusion to dealing with things that go bump, ARP, or otherwise collide in the night.

Double reverse slam-dunks: Reversing the ARP protocol

As we saw in my March column, ARP is used to locate the hardware, or MAC address for a given IP address. It takes the logical, 32-bit IP addresses like 192.9.200.1 and associates with it a 48-bit physical address like 8:0:20:45:7:b, uniquely identifying the machine with the noted IP address. ARP is the workhorse for establishing IP-level connections to new, previously uncontacted hosts.

What do you do if you know your own MAC address, but need to find an IP address to use? Such is the case with diskless clients, network computers, and PCs that are configured without a name service or file of hostnames and IP addresses -- they can look up their own MAC addresses in hardware, but have to ask some network authority to supply the correct IP address. The most common suppliers of the IP address are Sun's diskless workstation boot parameter (bootparam) remote procedure call, the bootp client booting protocol, and the Dynamic Host Configuration Protocol (DHCP). DHCP is described in RFC 983, and is at the heart of many PC-LAN based TCP/IP configurations. All of these protocols use Reverse ARP (RARP) to match the MAC address to a corresponding IP address.

RARP differs from ARP in more than just the direction of the lookup; while ARP is a full-fledged part of a TCP/IP implementation, RARP is almost always handled in a user-level process on the server side. You'll see the in.rarpd server daemon opening on /dev/dlpi (in Solaris) or /dev/nit (in SunOS), extracting raw RARP broadcast frames off the network. Why bother implementing a network layer protocol in user space? The short answer is "configuration control." RARP uses the /etc/ethers file or the ethers NIS map to correlate MAC addresses to IP addresses; this is maintained by you, our gentle reader, in the same manner that IP address-to-host name mappings are noted in a hosts file. The diskless client booting protocol uses other configuration files to indicate the location of the root and /usr filesystems, and DHCP has its own set of user-level files as well. More information can be found in the manual page for rarpd .

We're taking this detour through RARP land primarily for completeness. ARP failures tend to be dramatic and affect entire network segments -- and that's when you're just using the dynamically inserted ARP entries. We'll look at further complications shortly. ARP troubles appear as slow or intermittent network connections, hideous network file access performance, and the occasional broadcast storm. RARP difficulties, on the other hand, tend to blow up one machine at a time. You'll see machines that hang during boot or fail to boot cleanly, or can't configure network interfaces correctly.

If you see messages of the form

 revarp: no response for MAC address 8:0:20:a:b:c
 

while booting your desktop, it means that the system couldn't determine a valid IP address for itself during the boot sequence. Check your hostname configuration in /etc/nodename, /etc/hostname.le0 (or /etc/hostname.hme0 if you're Ultra-inclined) and in the /etc/hosts file; if there are inconsistencies your desktop may decide to ask the network to supply the missing IP bits. More likely, you have an empty /etc/hostname.le0 file, so the host configures its le0 interface but can't figure out the IP address from the (missing) host name. What you'll see if you look in /etc/init.d/rootusr is a line of the form

 ifconfig -a auto-revarp
 

that indicates the RARP protocol should be used to configure the built-in interfaces.

Proxy votes: Hiding hideous hairballs with proxy ARP

A proxy server is simply one that "stands in" for the real McCoy, much like a stockholder casts a proxy vote at the annual meeting of a publicly traded company instead of personally attending the meeting to vote in person. Proxy ARP is a publicly available package that allows a machine to answer ARP requests for others that can't be there to answer the requests on their own behalf.

Here's an ideal example: you're supporting several remote workstations connected over PPP links to a router attached to one of your LAN campus segments. To conserve IP networks, you'd really like to keep the remote machines on the same IP network as the local ones, merely "giving away" a few IP addresses to the remote machines and their PPP end points on the router. While this is ideal from a configuration management point of view, it's a nightmare for your routers and other machines that need to reach these remote workstations. Creating host routes for the remote machines only partially solves the problem; those machines on the same IP network aren't going to be looking for a router to get to machines that are ostensibly on the same wire.

Proxy ARP fits the bill nicely -- it allows you to designate one machine to answer ARP requests for the remote machines, providing the MAC address of the router with the PPP end points on it. The router can then handle forwarding to the appropriate destination. Why wouldn't you use published ARP entries on the proxy ARP server? Publishing an ARP entry has the same effect as using proxy ARP, namely, the server answers ARP requests for the IP address in the entry, supplying the matching MAC address (not its own). However, published ARP entries fill a slot in the ARP cache, making this solution minimally scalable. Publishing ARP entries is adequate for a handful of remote machines; to support several dozen you'll do better with a proxy ARP server so that the server's ARP cache doesn't become half-full of infrequently used entries.

The big zero: Multiple IP networks on a single wire

Proxy ARP services let you spread a single IP network over several physical segments, saving the virtual real estate of your IP address space while minimizing complexity. How do you do the opposite, that is, put several logical IP networks on the same physical network segment? Better yet, why would you want to do such a thing in the first place? Think about migrating to a new IP addressing scheme, a new network topology, or merging two networks together. You're going to go through a phase where you want old and new network numbers to live together on the same wire, or where you've consolidated two or more LANs onto the same physical segment while migrating to Fast Ethernet, ATM, or an FDDI ring design. As Ethernet switches gain in popularity, the creation of virtual LANs (VLANs) often requires running more than one IP network on a series of ports switched like a single segment; rather than renumber your machines you can work around the IP routing issues with a clever combination of route definition and ARP fiddling.

There are two ways to solve this IP migration problem: supply each machine with routing information so it knows that both networks are on the same wire, or give each machine an IP address on each network so that it has explicit connectivity to each logical network. The multiple IP address per network interface trick is useful when you need to make a machine appear with several names, for example, when you're hosting Web content for more than one named host.

To merge the IP networks with the routing solution, you use a zero-cost route that indicates the target network is directly connected to the local machine. Let's assume the first IP network is 192.9.200.0, and the "new" network is 201.2.14.0. To add a route to the 201-network, you'd insert the following line in /etc/init.d/inetsvc:

 huey# route add network 201.2.14.0 `cat /etc/hostname.le0` 0 

Zero-cost routes imply that the local machine will send an ARP request for each machine on the target network, since that network is accessible over the local le0 interface. Normally, a host will send an ARP request using the IP address of the designated router for the network; but in this case the router is the machine itself so it does the ARP for the destination IP address. Strange-looking ARP requests for IP addresses that shouldn't be on a particular network segment may be caused by a misplaced zero-cost route.

Here's a corner case where proxy ARP once again comes to the rescue: While merging two IP networks together, you have some "old" machines that have no need to reach other systems on the same network, but have to use the single router that has an IP address on the "new" IP network. That is, router 201.2.14.100 has to handle packets from hosts 192.9.200.x, and you don't want to create zero-cost routes on every one of those machines. Using proxy ARP or a published ARP entry on one of the 201.2.14.x machines, create a "fake" IP address for the router on the 192.9.200.0 network, say, 192.9.200.100. Then insert an ARP entry using the MAC address of the router, so that ARP requests for IP address 192.9.200.100 are answered with the Ethernet address of your router, and packets will be delivered to the router from hosts on the 192.9.200.x network. Make sure those "old" machines put 192.9.200.100 in their /etc/defaultrouter files, or otherwise manually set up a route through the "fake" IP address. Note that this address won't appear in RIP packets or other routing information, so you'll have to use a route command, an entry in /etc/gateways, or a default route to point your old machines at the router of multiple personalities.

More Multiple Personalities: Virtual interfaces

When you're renumbering a network or trying to make a machine impersonate multiple personalities, you need to create virtual interfaces on top of a single physical network interface. For SunOS users, you'll need a package called vif , written by John Ioannidis while at Columbia University. Solaris has this feature built into the ifconfig command and IP implementation. Virtual interfaces use notations of le0:1, le0:2, le0:3 and so on to number the virtual interfaces created on top of the le0 device. Solaris 2.5 and earlier releases have a limit of 256 virtual interfaces per physical network connection; this limit is relaxed in Solaris 2.5.1/Internet supplement and later releases.

Turn on the virtual interface by adding lines like the following to a new boot script called /etc/rc2.d/S99vif:

huey# ifconfig le0:1 hostname-net1 broadcast + netmask +
huey# ifconfig le0:2 hostname-net2 broadcast + netmask +

There's no need to "plumb" the virtual interface because the necessary STREAMS code was pushed onto the physical interface when it was configured earlier in the boot process. Virtual interfaces simply add more IP addresses to the same underlying device. The explicit ifconfig command sets the broadcast address and netmask. Virtual interfaces aren't handled nicely by the /etc/hostname.le0 convention, as the boot code that reads those files expects to plumb, configure, and RARP as needed. Life is simpler when you're telling these little white IP lies, so stick the configuration in a separate boot file.

When you run multiple IP networks on the same physical segment, you may confuse some machines' routing tables. A typical problem is messages like "packet from unknown router" that appear when a machine receives a packet that comes from an IP address that does not appear to be on the local network. In our previous example, any machine on the 192.9.200.0 network may receive a packet from a router using IP address 201.2.14.100, but become confused when it finds that it has no direct connection to network 201.2.14.0. Adding a second IP address on the local interface, or a zero-cost route will dissipate the messages.

When you add second and consecutive IP addresses to an interface, you cause it to answer ARP requests for all of those addresses. The Solaris kernel maintains a list of IP addresses per interface and matches incoming ARP requests against this list. You'll see the same MAC address appearing in ARP caches tied to several IP addresses if you use the virtual interface mechanism, and that multiplicity could impair network management discovery tools or other scripts that rely on ARP cache browsing to build their view of the local network.

ARP is part of the kernel like the virtual memory system or the filesystem cache -- ideally you never have to deal with it or know that it's there, but when it breaks it wreaks havoc on your day to day operations. Knowing where to poke it, how to watch for trouble and trace it back will help you keep too many things from bumping into each other in the dark.

Hal Stern is a Distinguished Systems Engineer at Sun Microsystems, where he specializes in information systems architecture, technology evangelism, and answering email.

Linux.com Ping ICMP vs. ARP

If traditional ICMP-based pings are no longer reliable unless you know in advance that there is no firewall blocking ICMP echo requests, what other options exist? One option is an Address Resolution Protocol (ARP) based ping using the arping utility.

To know why ARP pings are virtually guaranteed to work while ICMP pings may not, one should understand the importance of ARP in networking. ARP is used by hosts on a network to resolve IP addresses into Media Access Control (MAC) addresses, which can be interpreted as a network interface's unique serial number. Hosts on an Ethernet network use MAC addresses rather than IP addresses to communicate.

When a host tries to create a connection to another host (on the same subnet), it first needs to obtain the second host's MAC address. In this process, Host A sends an ARP request to the broadcast address of the subnet to which it is connected. Every host on the subnet receives this broadcast, and the host with the IP address in question sends an ARP reply back to Host A with its MAC address. After receiving the ARP reply from Host B, Host A can connect to Host B.

ARP is required for an Ethernet network to function properly, so it typically is not blocked by a firewall. If ARP requests were blocked, no host would be able to "find" a computer on a network and connect to it. For all intents and purposes, the system would be unplugged from the network.

(Tools do exist to filter ARP. The ebtables project provides these tools. Ebtables is similar in both functionality and syntax to iptables, but whereas iptables works with TCP and UDP protocols, ebtables works with ARP.)

One possible drawback to this system of using ARP to ping a host is that the ARP protocol is not a routed protocol. If you are not on the same subnet as the host you are trying to connect to, then this method is not going to work without first joining that subnet, which may or may not be physically possible. Thus by sending an ARP request rather than an ICMP echo, you are virtually guaranteed to get a reply.

Let's explore the most convenient ways to obtain ARP replies.

ARP table

When you attempt to ping an IP address, an ARP request is sent at the same time. Your firewall may be blocking the ICMP echo, but chances are the computer will receive an ARP reply. Your computer's ARP table will contain the IP address and MAC address of the host you are trying to reach.

Let's look at some of the ways to view the ARP tables. The first option is to use the ip neighborcommand

gerard@garion:~$ ip neighbor | grep 192.168.1.100
192.168.1.100 dev eth0 lladdr 00:40:05:01:fc:1e nud reachable

The ip utility used here is part of the relatively new package iproute2 that is designed to replace traditional utilities such as ifconfig , route , and arp . If your Linux system does not come with iproute2 installed, you can use arp instead of ip neighbor .

In this example, the IP address has a MAC address (lladdr) and a Neighbor Unreachability Detection (nud) of reachable in the ARP table. This means that the host belonging to IP address 192.168.1.100 is online and active, but is apparently blocking ICMP echo requests.

If this host were truly offline, the ip neighbor command's output would be similar to this:

gerard@garion:~$ ip neighbor | grep 192.168.1.101
192.168.1.101 dev eth0 nud failed

A nud of failed means there was no ARP reply after having sent out the ARP request to find this host.

www.delmar.edu/Courses/ITNW1325/sem1/notes/lessons16-19.html

Cisco Semester 1 (Lessons 16-19 notes) RARP requests have the same structure as ARP requests. Thus, RARP requests consist of a MAC header, an IP header, and the ARP request message. ... - 23k

http://www.cs.sunysb.edu/~cse533/asgn4/asgn4.html

http://www.tldp.org/LDP/tlk/net/net.html

http://www.microsoft.com/technet/archive/winntas/maintain/tcpip.mspx

Archived content - No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Chapter 3 from Firewalls, 24 seven, published by Sybex, Inc.

If you are reading this book, you presumably have a good understanding of how computers work and you have a working knowledge of how to use Internet tools such as Web browsers, Telnet, and e-mail. You might not, however, know just how your computer connects to other computers and downloads Web pages, exchanges e-mail, or establishes a Telnet session. This chapter will give you a better idea of what is going on behind the scenes.

www.cisco.com/univercd/cc/td/doc/product/software/ssr83/rpc_r/48383.htm Routing IP

Reverse Address Resolution Using RARP and BootP. Reverse ARP (RARP) was defined
in RFC 903. If a router does not know the IP address of one of its Ethernet ...
- 169k

[Mar 16 2005]Protection Against Arp Poisoning...

Been playing alot with Cain and Abel recently and after realising how powerful this tool is for sniffing traffic I want to now focus on counter measures against an attack this tool can perform - ARP poisoning. So can anyone recommend the best tools / techniques to protect against this?

EDIT: Just found this is already been covered on GovSec in the past. Im currently reading this paper that was recommended: http://www.cs.sjsu.edu/faculty/stamp/stude...ilky_report.pdf

However, i would like to hear from peoples experience on protecting against ARP poisoning and tools they have used.

www.leastprivilege.com - ARP Spoofing and XP SP2

I don't know what Microsoft has changed to the ARP cache behaviour...but ARP spoofing attacks are still possible!

You can easily reproduce that (you need at least three machines - one could also be a router) -

• Download and start Cain
• Click "Configure" and select the appropriate network interface
• Activate the Sniffer and go to the "Sniffer" Tab
• Click the "+" Icon - Cain will now scan the subnet for all attached devices (in my case my laptop with XP SP2 installed and the cisco router which is my default gateway)
• Go to the "APR Tab" (ARP Poisoning & Routing)
• Click the "+" Icon
• Now select the machine(s) which communication you wan to redirect to your machine (in my case i selected the laptop on the left and the router on the right)
• Activate APR

That's it - now all the traffic between the router and the laptop passes my machine (even in a switched network). Cain can recognize and collect various passwords directly from the wire including ftp, http forms auth, telnet, pop3, sql server...you can see the collected passwords on the "Passwords" tab. Those passwords that need cracking can be sent with right-click "send to cracker" to a cracking module (e.g. ntlm, kerberos pre-authentication...).

To get more insight into the packets just fire up ethereal on your machine and you'll get the full story.

So whatever they did, those SP2 changes don't increase the protection from these attacks. maybe they make it harder to start an attack from SP2 - and then again this is as stupid as removing raw sockets...
In fact i already saw operating systems with working anti ARP spoofing measures, e.g. the Cisco IOS. If they see a ARP broadcast on the wire where someone pretends to be them they immediately send a bunch of correct ARP packets out on the network.

an excellent explanation of how ARP spoofing works can be found here.

btw - the only protection against ARP spoofing at the moment (on Windows) is to add static ARP entries in the cache, e.g. for your standard gateway with

arp -s IPAddress MACAdress

...but who does that?

OptimumPath Secure Wireless Router

RE: [suse-security] What to do against ARP-Poisoning?

From: Reckhard, Tobias ([email protected])
Date: Tue Mar 19 2002 - 22:31:42 PST

Next message: Robert Klein: "Re: [suse-security] Firewall2 Logs"

• Previous message: Alex Levit: "Re: [suse-security] Kaspersky AVP on SuSE mail server III"

• Maybe in reply to: Roland Hilkenbach: "[suse-security] What to do against ARP-Poisoning?"

• Next in thread: Andy Spiers: "Re: [suse-security] What to do against ARP-Poisoning?"

• Reply: Andy Spiers: "Re: [suse-security] What to do against ARP-Poisoning?"

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

> > And remember that switches aren't security enforcement devices and
> > shouldn't be expected to be.
>
> The 3com switches that we have (SuperStack II) certainly have
> some active
> security measures. Enabling "Port Security" on a port makes
> the switch
> remember the first MAC address it receives and locks that MAC
> address to that
> port until overridden by manual intervention. Although
> unfortunately they
> cannot perform any kind of ARP poison countermeasures.

AFAIK, some other switches even let you configure the valid MAC addresses
per port. However, there have been reports of switches being confused if
they're swamped with MAC addresses and resorting to broadcast mode.
Actually, that's perfectly normal spanning tree algorithm behaviour, that
algorithm being the basis of all switches. As such, it's buried deep in the
devices' logic and it probably isn't being disabled by 'port security'.
Switches have some features that are marketed as security benefits, and some
even are, but switches remain devices designed to provide efficient
connectivity, i.e. mainly speed. They are not designed as security
enforcers, while other devices, e.g. firewalls, are (or should be).

One can even argue that it is a Bad Idea (TM) to use managed switches in
sensitive environments, because the switch constitutes a further point of
attack and often a single point of failure. The point is strengthened by the
fact that the OS on switches is generally not designed with security a top
priority, it usually supports a number of services (Cisco switches, e.g.
support NTP, SNMP, TFTP, Telnet, CDP) that can be exploited. And more often
than not, I wager, the personnel is pretty clueless with regards to the
switch configuration, since these boxes are typically plug'n'play.

Now don't get me started on VLANs. Just this much: don't use VLANs to
'separate' networks of (more or less substantially) different trust.
Instead, implement physical separation.

Tobias

Security Basics: Re: ARP Poisoning

From: ATD (simon_at_snosoft.com)
Date: Nov 08 2002

• Next message: bsec: "Re: Symantec Corporate AntiVirus 8.0 - thoughts"
• Previous message: sanjay.patel_at_rexwire.com: "RE: Biometric question"
• In reply to: Michael Ungar: "ARP Poisoning"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

---

Well,
One easy way to ID this is to monitor for the ARP broadcast, or check for hosts doing this broadcast. For example... when using ettercap (one of those nice arp tools) ot does:

Building host list for netmask 255.255.255.0, please wait...
Sending 7 ARP request... <--- You can detect this.

Another thing that you can do is to run checks for other systems doing
arp poisoning, ettercap offers this feature as well:

[cC] - check for other poisoner...

So, one way to defend against this sniffing is to check for these
poisoners every X minutes and notify the admin IF such a thing happens.

Cerebrum Gateway]
<gawd# ettercap -c -N

ettercap 0.6.7 (c) 2002 ALoR & NaGA

Your IP: xxx.xxx.xxx.xxx with MAC: 00:10:4B:C8:2A:4E on Iface: de0
Building host list for netmask 255.255.255.0, please wait...

Sending 7 ARP request...

* |==================================================| 100.00 %

Resolving 5 hostnames...
* |==================================================| 100.00 %

Checking for poisoners...

MAC of xxx.xxx.xxx.xxx and xxx.xxx.xxx.xxx are identical !

you got a poisoner!!! =o)

Security Basics Re ARP Poisoning

http://www.oxid.it/downloads/apr-intro.swf Intro to ARP spoofing

SANS Intrusion Detection FAQWhy your switched network isn't secure.

http://webopedia.internet.com/TERM/s/segment.html

http://www.AntiOnline.com/cgi-bin/anticode/anticode.pl "AntiCode Website"

http://www.insecure.org/

http://thc.inferno.tusculum.edu/files/thc/parasite-0.5.tar.gz van Hauser. "Parasite 0.5"

http://www.monkey.org/~dugsong/dsniff/ Song, Dug. "Dsniff"

Protection from ARP Spoofing Attacks - Protection ARP Guard

Angriff von Innen

by Gereon Ruetten und Oliver Stutzke (2005)
Nicht nur aus dem Internet werden PCs angegriffen, um Trojaner und Spyware zu installieren. Auch im LAN, beispielsweise in der Firma, versuchen bösartige Zeitgenossen Informationen auszuspähen. Selbst geswitchte Netzwerke bieten keinen Schutz, wenn Angreifer die Verbindung mittels ARP-Spoofing über sich umleiten.

The Insider Threat Study by US Secret Service (2005)

This study [...] is the first of its kind to provide a comprehensive analysis of insider actions by analyzing both the behavioral and technical aspects of the threats. The findings underscore the importance of organizations' technology, policies and procedures in securing their networks against insider threats, as most of the cases showcased in the report were perpetrated by insiders with minimal technical skills. Various proactive practices are among the suggestions offered by the report.

Recommended Papers

[****] Silky_report ARP Cache Poisoning Prevention and Detection. Silky Manwani. CS 298 Project. 1. San Jose State University. ARP Cache Poisoning Detection and Prevention ...

comnet0103

Playing redir games with ARP and ICMP by yuri volobuev

[PDF] Hijacking a Network Connection on a Switched Network

Security Reference Guide

The Cain Sniffer

A sniffer is a program that can capture data as it travels on a network. As previously discussed, the amount of traffic the sniffer has access to depend on whether or not the network card is in promiscuous mode. In addition, with the advent of the switch, a computer no longer has access to all the data flowing on the network. Thanks to smart switching devices, a computers network card will only be passed information to which it is addressed, or if the data is meant for all connected computers (broadcast). As a result, even if a network card is placed in promiscuous mode, it is not necessarily going to be able to sniff network traffic.

When a switch is initialized, it determines the MAC address of the card connected to each port. As the network cards communicated, the switch monitors the data and creates a table linking IP address with MAC address. Then when a data packet enters into the switch, it compares the destination IP address with the list of devices in its MAC address table to see which port it is to send the data on to. This table is called the ARP table.

The Address Resolution Protocol (ARP) is the standard that defines how MAC addresses are linked to IP addressed. However, there is a sight weakness in the protocol that allows a user to lie to a computer about the IP to MAC address translation. As a result, it is possible to trick two network devices into passing all their network traffic to a deceitful computer that can simply capture and then pass the information on to the intended target. This process is known as ARP Spoofing, and it allows a computer to sniff network traffic even if there is a switch.

ARP command

The ARP table, cached in memory, stores requested Ethernet addresses for up to 20 minutes. If an Ethernet address does not appear in the ARP table, an ARP request is sent.

Solicited ARP entries cache for 20 minutes, while unsolicited ARP entries cache for 5 minutes.

Most important commands

• arp -a -- view cashe
• arp hostname To examine a specific ARP table entry, perform the command.
• arp -s hostname ethernet_address To add a static (until reboot) ARP table entry, perform the command.
• # arp -s hostname ethernet_address pub To add a published ARP table entry, perform the command:
• To add ARP entries from a file, perform the command:

  # arp -f filename

  Entries in the file should be in the form:

  hostname ethernet_address [pub]

• To delete an ARP table entry, perform the command:

  # arp -d hostname

ARP vulnerabiltities

Anatomy of an ARP Poisoning Attack. by Corey Nachreiner, WatchGuard Network Security Analyst

ARP poisoning enables local hackers to cause general networking mayhem. Because it's mostly "incurable," every administrator should be aware of how this attack works.

ARP Refresher

In Foundations: What Are NIC, MAC, and ARP?, we explained that Address Resolution Protocol (ARP) is how network devices associate MAC addresses with IP Addresses so that devices on the local network can find each other. ARP is basically a form of networking roll call.

ARP, a very simple protocol, consists of merely four basic message types:

1. An ARP Request. Computer A asks the network, "Who has this IP address?"
2. An ARP Reply. Computer B tells Computer A, "I have that IP. My MAC address is [whatever it is]."
3. A Reverse ARP Request (RARP). Same concept as ARP Request, but Computer A asks, "Who has this MAC address?"
4. A RARP Reply. Computer B tells Computer A, "I have that MAC. My IP address is [whatever it is]"

All network devices have an ARP table, a short-term memory of all the IP addresses and MAC addresses the device has already matched together. The ARP table ensures that the device doesn't have to repeat ARP Requests for devices it has already communicated with.

Here's an example of a normal ARP communication. Jessica, the receptionist, tells Word to print the latest company contact list. This is her first print job today. Her computer (IP address 192.168.0.16) wants to send the print job to the office's HP LaserJet printer (IP address 192.168.0.45). So Jessica's computer broadcasts an ARP Request to the entire local network asking, "Who has the IP address, 192.168.0.45?" as seen in Diagram 1.

All the devices on the network ignore this ARP Request, except for the HP LaserJet printer. The printer recognizes its own IP in the request and sends an ARP Reply: "Hey, my IP address is 192.168.0.45. Here is my MAC address: 00:90:7F:12:DE:7F," as in Diagram 2.

Now Jessica's computer knows the printer's MAC address. It sends the print job to the correct device, and it also associates the printer's MAC address of 00:90:7F:12:DE:7F with the printer's IP address of 192.168.0.45 in its ARP table.

Hey ARP, Did You Know Gullible Is Not in the Dictionary?

The founders of networking probably simplified the communication process for ARP so that it would function efficiently. Unfortunately, this simplicity also leads to major insecurity. Know why my short description of ARP doesn't mention any sort of authentication method? Because in ARP, there is none.

ARP is very trusting, as in, gullible. When a networked device sends an ARP request, it simply trusts that when the ARP reply comes in, it really does come from the correct device. ARP provides no way to verify that the responding device is really who it says it is. In fact, many operating systems implement ARP so trustingly that devices that have not made an ARP request still accept ARP replies from other devices.

OK, so think like a malicious hacker. You just learned that the ARP protocol has no way of verifying ARP replies. You've learned many devices accept ARP replies before even requesting them. Hmmm. Well, why don't I craft a perfectly valid, yet malicious, ARP reply containing any arbitrary IP and MAC address I choose? Since my victim's computer will blindly accept the ARP entry into its ARP table, I can force my victim's gullible computer into thinking any IP is related to any MAC address I want. Better yet, I can broadcast my faked ARP reply to my victim's entire network and fool all his computers. Muahahahahaa!

Back to reality. Now you probably understand why this common technique is called ARP Cache Poisoning (or just ARP Poisoning): the attacker lies to a device on your network, corrupting or "poisoning" its understanding of where other devices are. This frighteningly simple procedure enables the hacker to cause a variety of networking woes, described next.

All Your ARP Are Belong To Us!

The ability to associate any IP address with any MAC address provides hackers with many attack vectors, including Denial of Service, Man in the Middle, and MAC Flooding.

Denial of Service

A hacker can easily associate an operationally significant IP address to a false MAC address. For instance, a hacker can send an ARP reply associating your network router's IP address with a MAC address that doesn't exist. Your computers believe they know where your default gateway is, but in reality they're sending any packet whose destination is not on the local segment, into the Great Bit Bucket in the Sky. In one move, the hacker has cut off your network from the Internet.

Man in the Middle

A hacker can exploit ARP Cache Poisoning to intercept network traffic between two devices in your network. For instance, let's say the hacker wants to see all the traffic between your computer, 192.168.0.12, and your Internet router, 192.168.0.1. The hacker begins by sending a malicious ARP "reply" (for which there was no previous request) to your router, associating his computer's MAC address with 192.168.0.12 (see Diagram 3).

Now your router thinks the hacker's computer is your computer.

Next, the hacker sends a malicious ARP reply to your computer, associating his MAC Address with 192.168.0.1 (see Diagram 4).

Now your machine thinks the hacker's computer is your router.

Finally, the hacker turns on an operating system feature called IP forwarding. This feature enables the hacker's machine to forward any network traffic it receives from your computer to the router (shown in Diagram 5).

Now, whenever you try to go to the Internet, your computer sends the network traffic to the hacker's machine, which it then forwards to the real router. Since the hacker is still forwarding your traffic to the Internet router, you remain unaware that he is intercepting all your network traffic and perhaps also sniffing your clear text passwords or hijacking your secured Internet sessions.

MAC Flooding

MAC Flooding is an ARP Cache Poisoning technique aimed at network switches. (If you need a reminder about the difference between a hub and a switch, see this sidebar.) When certain switches are overloaded they often drop into a "hub" mode. In "hub" mode, the switch is too busy to enforce its port security features and just broadcasts all network traffic to every computer in your network. By flooding a switch's ARP table with a ton of spoofed ARP replies, a hacker can overload many vendor's switches and then packet sniff your network while the switch is in "hub" mode.

Scared? Good, Now Calm Down!

This is scary stuff. ARP Cache Poisoning is trivial to exploit yet it can result in very significant network compromise. However, before you jump to Defcon-7, notice the major mitigating factor: only local attackers can exploit ARP's insecurities. A hacker would need either physical access to your network, or control of a machine on your local network, in order to deliver an ARP Cache Poisoning attack. ARP's insecurities can't be exploited remotely.

That said, hackers have been known to gain local access to networks. Good network administrators should be aware of ARP Cache Poisoning techniques.

Since ARP Cache Poisoning results from a lack of security in a protocol that is required for TCP/IP networking to function, you can't fix it. But you can help prevent ARP attacks using the following techniques.

For Small Networks

If you manage a small network, you might try using static IP addresses and static ARP tables. Using CLI commands, such as "ipconfig /all" in Windows or "ifconfig" in 'NIX, you can learn the IP address and MAC address of every device in your network. Then using the "arp -s" command, you can add static ARP entries for all your known devices. "Static" means unchanging; this prevents hackers from adding spoofed ARP entries for devices in your network. You can even create a login script that would add these static entries to your PCs as they boot.

However, static ARP entries are hard to maintain; impossible in large networks. That's because every device you add to your network has to be manually added to your ARP script or entered into each machine's ARP table. But if you manage fewer than two dozen devices, this technique might work for you.

For Large Networks

If you manage a large network, research your network switch's "Port Security" features. One "Port Security" feature lets you force your switch to allow only one MAC address for each physical port on the switch. This feature prevents hackers from changing the MAC address of their machine or from trying to map more than one MAC address to their machine. It can often help prevent ARP-based Man-in-the-Middle attacks.

For All Networks

Your best defense is understanding ARP Poisoning and monitoring for it. I'd highly recommend deploying an ARP monitoring tool, such as ARPwatch, to alert you when unusual ARP communication occurs. This kind of vigilance is still the greatest weapon against all kinds of attack -- for, as Robert Louis Stevenson wrote, "The cruelest lies are often told in silence."

Resources:
Address Resolution Protocol Spoofing and Man-in-the-Middle Attacks

[Sept 27, 2001] ARP Vulnerabilities The Complete Documentation by Robert Wagner

Address Resolution Protocol Spoofing and Man-in-the-Middle Attacks

The classic Man-in-the-Middle attack relies upon convincing two hosts that the computer in the middle is the other host. This can be accomplished with a domain name spoof if the system is using DNS to identify the other host or address resolution protocol (ARP) spoofing on the LAN. This paper is designed to introduce and explain ARP spoofing. The term Man-in-the-Middle is used from a historical usage, this does not imply that only men can use these attacks. Perhaps Teenager-in-the-Middle or Monkey-in-the-Middle may be more accurate terms.

Altering ARP Tables

Published on 2001- by DataWizard, ©PacketStorm Security.

After month's of doing everything except writing a new paper or updating an old one, I'm back with a new subject. Because I only want to write about subjects that are not very common, I will not publish much tutorials/papers in the future. This paper is dedicated to ARP tables and how to alter them remotely. The paper also describes a couple of implemantations of ARP poisoning in a bridge based segment and a couple of ways to protect yourself. As usual: I'm not responsible for any of your stupid actions while practicing the following info at places you shouldn't be.

ARP Vulnerabilities Indefensible Local Network Attacks?

Published on July 12, 2001- by Mike Beekey, ©Black Hat Briefing.

ARP may be one of the most used, but least respected protocol allowing two devices to establish communications with each other across a network. Unfortunately, even with its critical role of mapping the logical address to physical address, ARP is inherently susceptible to a variety of spoofing attacks within local subnets. While there have been discussions surrounding this issue and tools written to take advantage of these features, its potential to cause nearly indefensible denial of service attacks with minimal effort, appears to still be understood by only a few.

Introduction to ARP Spoofing (An)

Published on April 2001- by Sean Whalen, ©Chocobospore.

This paper deals with the subject of ARP spoofing. ARP spoofing is a method of exploiting the interaction of IP and Ethernet protocols. It is only applicable to Ethernet networks running IP. The subject will be addressed such that anyone with basic networking experience can understand key points of the subject. Knowledge of the TCP/IP reference model is vital to full understanding, as is a familiarity with the operation of switched and non-switched networks. Some background will be presented in the "Introduction" section, but experienced readers may wish to skip to "Operation".

IP Smart Spoofing (The)

Published on October 2002- by Laurent Licour, Vincent Royer, ©Althes.

This paper describe a new method for spoofing an IP address with any networking application. IP spoofing is not new and various hacking tools have been developed to exploit it. In the following, we will discuss on the way to use it with any standard application. As a result, we will explain why IP based access control is not reliable in many cases, and should not be used in many corporate.

MAC Addressing and ARP Functionality

Published on 2003-10-09- by L33tdawg, ©HackinTheBox.

The Media Access Control (MAC) address, also known as an Ethernet address, is the physical/hardware address for devices that are connected to a network, usually a LAN. Each node connected to the network has it's own unique MAC address hard coded (burned) into its Network Interface Card (NIC) by the manufacturer and uses this address to find and communicate with other devices on the same network domain or wire.

Middleware approach to asynchronous and backward compatible detection and prevention of ARP cache poisoning (A)

Published on 1999-12-10- by Mahesh V. Tripunitara, Partha Dutta, ©Annual Computer Security Applications Conference.

We discuss the Address Resolution Protocol (ARP) and the problem of ARP cache poisoning. ARP cache poisoning is the malicious act, of a host in a LAN, of introducing a spurious IP address to Medium Access Control (MAC) address mapping in another host's ARP cache. We discuss design constraints for a solution: the solutions needs to be implemented in middleware, without access or change to any operating system source code, be backward-compatible to the existing protocol, and be asynchronous.

Quick guide of what you can do with ARP

Published on 2002-08-07- by Frédéric Raynal, ©ARP-SK.

If ARP is a well known protocol, the attacks it allows are often restricted to sniffing, while so many are possible.

Taranis read your e-mail

Published on August 11, 2001- by Jonathan Wilkins, ©Phrack Magazine.

Taranis redirects traffic on switch hardware by sending spoofed ethernet traffic. This is not the same as an ARP poisoning attack as it affects only the switch, and doesn't rely on ARP packets. Plus, it is virtually invisible because the packets it sends aren't seen on any other port on the switch. Evading detection by an IDS that may be listening on a monitoring port is as simple as changing the type of packet that is sent by the packet spoofing thread.

Wireless Access Points and ARP Poisoning: Wireless vulnerabilities that expose the wired network

Published on October 22, 2001- by Bob Fleck, Jordan Dimov, ©Cigital, Inc..

Wireless networks, specifically 802.11b, have received a tremendous amount of interest and scrutiny from the security community over the past few months. The security community agrees that wireless networks introduce a new point of entry into previously closed wired networks and must thus be treated as an untrusted source, just like the Internet. Standard technologies enable wireless client machines to connect to a local area network made up of other wireless hosts. For wireless networking to be most useful, the wireless networks must pass data on to standard wired networks connected to the Internet. This paper describes the application of a well understood class of attacks on wired networks to the emerging mix of wired and wireless networking equipment.

Arp Spoofing (cache poisoning)

Many people think that once they use a switch for connecting their local network they're safe from network sniffing. Basically this is right because the traditional way of sniffing where a host can read all network packets just by accepting them (the so called "promiscuous mode") is not possible.

However there are other means to achieve the same and because maybe some SysAdmins think they're safe from sniffing thus designing their network a bit more open it's even more dangerous.

The tool used here is called arpspoof and is distributed in the dsniff package.

What we do is the following: We constantly send the victim computer ARP answers telling him that the MAC address belonging to the IP of the gateway machine (router) is our MAC address. After some time the victim computer will believe us and makes a wrong entry in his ARP cache. Next time the victim wants to send an IP packet to the gateway he sends the ethernet frame to our MAC address so actually we get the IP packet. We do the same thing with the gateway machine just the other way round.
RFC 1027 describes the ARP protocol.

In order to tell the victim host that now we (our MAC address) are the one belonging to the IP of the gateway enter the following command:
# arpspoof -t victim gateway

In a seperate shell we start the matching command to fool gateway to believe we are victim.
# arpspoof -t gateway victim

Don't forget to enable IP forwarding on your host so that the traffic goes through your host. Otherwise victim will loose connectivity.
# echo 1 > /proc/sys/net/ipv4/ip_forward

Now watch all the traffic between the victim host and the outside network going through your machine
# tcpdump host victim and not arp

Frightening easy...

SysAdmins beware of that threat! If you have users on your network you can't trust (e.g. in universities) use tools like arpwatch to monitor the changes of the MAC / IP address tables.

Mac Filtering

Security Reference Guide MAC Filtering

Nov 15, 2006.

By default, every device on a wireless network has a unique address that's used to distinguish one wireless network interface card (WNIC) from another. This address is called the Media Access Control (MAC) address. In theory, since every WNIC has been pre-assigned a unique MAC address by the hardware vendor, an access point can be set up to only allow a pre-selected list of WNICs to connect. For example, the Linksys WAP11 includes a MAC filtering option in its software that allows an administrator to define who can connect to the WLAN by listing all the allowed MAC addresses. Once you have the MAC address of all the connecting WNICs, you can set up MAC filtering and enable it accordingly. This will stop many connection attempts made by unauthorized addresses.

However, while in theory this is an excellent way to stop hackers from accessing your WLAN, there's a serious flaw in MAC filtering: MAC addresses can be spoofed (faked) by changing WNIC settings. For example, the Dell TrueMobile includes software that allows a hacker to alter his MAC address to any address he chooses. Thus, this option is about as useful as trying to keep people from accessing a chat room by restricting chat handle names. To bypass such a restriction, a person only has to change his or her name.

Why would a software/hardware vendor want to allow a user to change a MAC address? Having the power to adjust a MAC address can provide a network administrator with more tools to keep control over the network. However, this increased power gives just as much control to an attacker. This is one example of how the ancient power struggle between user needs and security often plays right into an attacker's hands.

Regardless, if MAC filtering is an option, you should implement it on your WLAN. Just as with enabling WEP, MAC filtering does require a modicum of sniffing and network expertise. Thus, it can also serve as an intellectual barrier to most of the potential intruders of your wireless network. Note that if your WLAN supports more than 100 users, managing the MAC control list could be a time-consuming chore.

Firewalling.com - The guide to MAC Filtering.

MAC Filtering MAC Filtering is very important if you are on a wireless network. You are legally responsible for what is done on your network. MAC Filtering allows you to setup your network in two ways. MAC filtering usually allows you to prevent certain MAC addresses from accessing the internet. It will also allow certain MAC Addresses to access the internet and deny all others. The second setup is the one that you need to use. Most people take home their wireless router, plug it in, and never bother to setup MAC filtering. This is really bad. If MAC filtering is not setup anyone can use their network to access the internet. Hackers drive arround towns in their cars with their laptops trying to connect to the internet. These wireless routers are setup to hand out ip addresses via DHCP, so the second that a hacker gets in range they are on the net. The hacker is on your network what now? Well he could sniff the traffic on your network to find out what you are doing. He could also watch your network for credit card information or other vital financal information. That is not really likely. Most likely he will start hacking other peoples networks from yours. This is a huge concern, because it looks like you are attacking others. If you are in the states, you could have the FBI knocking on your door. I know this for a fact because I assisted the FBI in some instances while I worked for an isp. So here is fair warning! Setup MAC filtering now!

You can use MAC filtering to allow only certain MAC addresses to access the internet and prevent all others. This is really easy to do. First off you need to find the MAC address of every computer that will be connecting to the internet. Take a look at our Finding a MAC Address guide for help with this. I'm planning on writing a how to for every router I can find on this. For instructions on your specific router please visit our Routers page.

Quiz

Q1: What is the meaning of P flag in arp table listing

A: P is published entry flag. A system can be configured to publish 9advertize) an ARP entry on behave of systems that cannot respond to ARP requests.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019