Security in Wired/Wireless Networks:

Sniffing Attacks Prevention and Detection Techniques in Wired and Wireless Local Area Networks (LAN)

ABSTRACT

During the past era, Information Technology made a revolution in R&D. No doubt Internet becomes an essential backbone for all sciences and research nowadays. Accordingly security threats and data banks attacks turn out to be a phenomenon. Thus, granting protection to such crucial information becomes a high demand. While reviewing the latest studies in this area, there are strong signs that attacking information warehouse is the hot topic nowadays.

Moreover, preventing attacks to TCP/IP networks and what are the most efficient techniques to protect it, is the most targeted research area for security experts. For instance, what so called the Man-in-the-Middle attack [MiM] and Denial of Service [DoS] are just some ways of vulnerable attacks to TCP/IP networks, using some tools available free on the internet. They are sniffing the data traffic or causing service denial.

In our research, we evaluated the most famous security solutions and classifying them according to their efficiency against detecting or preventing the types of Address Resolution Protocol [ARP] Spoofing attacks. Based of the surprising experimental results in the security lab, we proposed an optimal algorithm to enhance their ability

Keywords:

Sniffing Attacks, ARP cache poisoning, Man-in-the-Middle [MiM], Intrusion Prevention & Detection technique [IPS/IDS], Denial of Service [DoS]

CHAPTER 1

INTRODUCTION

1.1 Overview

As we mentioned in the abstract section that this research is focusing on the internal attack within the local area network [LAN] which is forming the major and critical attacks which the network resources are exposed to according to recent studies conducted in the Information Security domain[1]. We will demonstrate two major attacks affecting the Internet users & the local network; The MiM attack[2] (Man-in-the-Middle Attack) and DoS (Denial-of-Service). There are many tools and softwares widely available and for free of cost which can carry out many attacks over the network and violate the privacy of users, such tools like Sniffers[3] monitors data traveling over a network, it either can be of authorized or unauthorized function. It was started initially as a Network Analyzer to help the Administrator to perform health check and maintain the network activities; however it is used today to redirect the traffic and access confidential files.

Traditionally, research in the area of information and communication security focused on helping developers of systems prevent security vulnerabilities in the systems they produce, before the systems are released to customers. the majority of studies on network security, are considering only the external attacks. Internal as well as external are of the outmost importance when it comes to information security, but need to be complemented with more depth research for developing detection and prevention mechanisms, and studying internal threats.

The research plan we followed in our work presented here are as follows:

a. Address Resolution Protocol [ARP]

b. ARP Spoofing attack [Poisoning]

c. ARP Spoofing based MiM & DoS attacks

d. Experiments

e. Optimal ARP Spoofing detection algorithm

f. Results & analysis

g. Conclusion

1.1.1 What is an ARP:

The Address Resolution Protocol (ARP) [4] is used by computers to map network addresses (IP) to physical addresses or what is usually refer to: Media Access Control addresses (MAC).

It translates IP addresses to Ethernet MAC addresses and classified as a Networking protocol used to find host's address given its IP address. Some network expert consider it as a DataLink Layer protocol because it only operates on the local area network or point-to-point link that a host is connected to[5]. The Address Resolution Protocol (ARP) is documented in RFC 826[1] and later it was adopted by other media, such as FDDI[6]. For more details about Internet Protocols Suits; see appendix [1]

1.1.2 How it works: The ARP Process & RARP

As we stated formerly from an architecture perspective, ARP is a layer 3 function (Network), however in a programming perspective ARP is considered as layer 2 (Datalink) because it calls the LAN data like layer code. RARP is stand for; Reverse Address Resolution Protocol, and it is a network protocol used to resolve a MAC address to the corresponding network layer address, i.e. RARP is used to map a MAC address to an IP address exactly the reverse function of the ARP request/reply.

1.1.3 Types of ARP/RARP protocol messages:

There are four types of ARP massages that are sent by an ARP protocol:

a. ARP request

b. ARP reply

c. RARP request

d. RARP reply

As we just said in the definition, ARP is used to map network address (IP) to physical address (MAC) and when a host need to communicate with another host it needs to know its MAC address. Here comes ARP protocol and works by broadcasting a packet (ARP-Request) for any hosts connected over the Ethernet network. The ARP packet contains the IP address of the sender and the IP address of the target it is interested in communicating with. See (1.2) and (1.3):

However, the target host, identifying that the IP address in the ARP request packet is belong to itself, so it returns an answer back in a unicast reply (ARP-Reply) and the host which initiated the ARP request catches the [IP,MAC] pair and keeps it in ARP cache memory. Keeping the host reply in cache will minimize the ARP traffic in the LAN. See (1.4):

So simply when the ARP request is broadcasted to all PC's on the network it asks the following question:

- Is x.x.x.x is your IP address?, if Yes send back your MAC address.

Then every PC checks if it's IP address is matching the one in ARP request and sends ARP reply with it's MAC address.

But the repeated ARP requests especially when it is broadcasted every time a MAC address is required; creates a high traffic in the network, and hence the Operating Systems keep copy of the ARP replies in the computer's cache memory and update it frequently with any new <IP, MAC> pair, this will help in reducing the ARP requests number[9].

By the way ARP spoofing technique which we are going to talk about in the next chapter is occurring when forged ARP replies <IP destination, MAC attacker> is created and sent to the source computer who initiated the ARP request formerly and updated it's ARP cache with fake information. We will know afterward this kind of exploitation is called "poisoning the ARP cache".

The Reverse Address Resolution Protocol [RARP] is broadcasting a RARP request packet with the target MAC address which will be received by all hosts in the Ethernet network. Host which its MAC address is matching the one in the RARP request will reply with its IP address in the RARP reply packet and sends it to the host which initiated the RARP request.

Afterward the IP address which consists of 32 bit will be converted to 48 bit Ethernet address, by the suitable encapsulation mechanism. This is the common practice for the Address Resolution Protocol (ARP), which is documented in RFC 826 [51].

ARP defines the exchanges between network interfaces connected to an Ethernet media segment in order to map an IP address to a link layer address on demand. Link layer addresses are hardware addresses (although they are not unchallengeable) on Ethernet cards; where the IP addresses are logical addresses assigned to machines attached to the Ethernet. Accordingly a Datalink layer address is known by other names, i.e. Ethernet Addresses, Media Access Control (MAC) Addresses, and even Hardware Addresses. However, the correct term from the kernel's perspective is "Link Layer Address" because this address can be changed via command line tools [50].

1.1.4 ARP and RARP message formats:

The ARP packet consists of Ethernet Header and Data packet; the Ethernet header is divided to:

- 6 bytes for the destination address

- 6 bytes for source address

- 2 bytes for the frame type in hexadecimal (e.g. 0806 for ARP & 8035 for RARP)

Where, the data packet structure of ARP packet is encapsulated and the information that every part holds are demonstrated in the following table[10]:

Table 1.1: ARP and RARP packet structure

+

Bits 0 - 7

Bits 8 - 15

Bits 16 - 31

0

Hardware type (HTYPE)

Protocol type (PTYPE)

32

Hardware length (HLEN)

Protocol length

(PLEN)

Operation (OPER)

64

Source hardware address [MAC] (SHA) (first 32 bits)

96

Source hardware address (last 16 bits)

Source protocol address (first 16 bits)

128

Sender protocol address (last 16 bits)

Destination hardware address (first 16 bits)

160

Destination hardware address (THA) (last 32 bits)

192

Destination protocol address (TPA)

- Hardware address type (2 bytes). 1=Ethernet

- Protocol address type ( 2 bytes). 0800H (hexadecimal) = IP address

- Operation type; 1 = ARP request, 2=ARP reply, 3=RARP request, 4=RARP reply

- etc….

1.1.5 TCP Standard Ports/Services

The table below is showing, a list of services and ports used by TCP protocol:

Table 1.2: TCP Ports and Services

Port #

Keywords

Description

20

FTP-DATA

File Transfer [Default Data]

21

FTP

File Transfer [Control]

23

TELNET

TelNet [Telecommunication network ]

25

SMTP

Simple Mail Transfer

37

TIME

Time

42

NAMESERVER

Host Name Server

43

NICNAME

Who Is

53

DOMAIN

Domain Name Server

79

FINGER

Finger

80

HTTP

WWW

110

POP3

Post Office Protocol - Version 3

111

SUNRPC

SUN Remote Procedure Call

CHAPTER 2

LITERATURE REVIEW

2.1 Background

2.1.1 ARP Spoofing based on MiM and DoS attacks

ARP spoofing is also called; ARP poison routing (ARP) or ARP cache poisoning or ARP Cache Corrupting. It is a method of attacking an Ethernet local area network by updating the target ARP cache with a forged ARP request and reply packets[9]. This will try to change the target MAC address by another one which the attacker has a control on it. Updating ARP cache with a fake entry value is so called "ARP Poisoning".

What is sniffer? or (The Network Analyzer); it is a software or a hardware which log the traffic over a network and captures the data packets, then decodes the packets and analyzes the content. Kindly notice in our research that the following terms; Spoofing, Poisoning and Cache Corrupting are referring to the same term .

Furthermore, since ARP is considered as a trusted protocol within the network and is not designed to deal with malicious activities in the network, so attackers found unusual ways to illegitimately penetrate into the network; causing harmful costs.

These harms or costs can be much worse when the attacker tries to impersonate another user, performs Man-in-the-Middle attacks (MiM), or even causes Denial of Service (DoS) on a Server or even the whole Network[11].

P.S. Spoof means: hoax or imitation. Thanks to the British comedian Arthur Roberts (1852-1933), who introduced the word "spoof" to the world in the 19th century. He invented a game and called it Spoof, it incorporates tricks & nonsense[12].

Why it is so difficult to detect sniffers?

• The attack is essentially performed in the passive mode, which means it is hidden and working in the backend so the standard user will not recognize such attacks. Besides it is not easily for user to detect the sniffing since this kind of attacks is generating usual traffic over the network.

• The other point is the fact that sniffers can be normally linked to an active intrusion attacks. While talking about the requirement and resources; sniffing is only requiring a standard machine connected over the network with normal hardware configurations and there is no need to special requirements or high performance.

• Threat is always seen as external and many researches shows that most of the attacks are from the internal resources; according to the recent Global security surveys in 2009[13], another study [14] shows that internal threat is incredible increased to more than 80% of the security breaches, where external attacks showed about 15% with internal help and 5% just from pure outsiders.

2.1.2 How ARP caches are updated?

Let us recall how the communication happens on an Ethernet LAN. As we early stated that all communications in layer 2 is based on the MAC address, so for any PC wants to talk to a target on the network is has to address it to the target's MAC address.

If a source computer tries to communicate with another computer in TCP/IP based network it has to translate the target's IP into the corresponding physical address (MAC) and here where we use an ARP protocol. The translation happens by request/reply ARP broadcast processes. When the ARP requester receives the reply, it catches the <IP,MAC> pair and keep it in it's ARP cache memory so it won't ask for it over again[15].

2.1.3 ARP Cache Poisoning (Spoofing) Attack

It is the process of corrupting an ARP cache with fake IP/MAC entries. It also used to perform some other attacks, for instance:

§ Man-in-the-Middle (MiM) attack, also known as (MITM)

§ Denial of Service (DoS) attack (refer to section 3.2)

As we discussed earlier if an entry is exist in the ARP cache, then it can be updated or corrupted using ARP reply or ARP request.

But what about if the entry; is NOT exist in the ARP cache? The answer is: ARP request packets always work to corrupt any Operating System ARP cache whether the entry exists or not in the ARP cache. On the other hand, for hackers, ARP requests allow them to corrupt always the target ARP caches!

A recent study[16] showed by experiment the impact of the ARP request update on different Operating Systems. An experiment revealed which OS with dynamic entries in the ARP cache was vulnerable to the ARP cache poisoning attack.

2.1 [17], an evaluation for the impact of the ARP request update on different Operating Systems, e.g. Windows XP Professional, Windows 2000, 2003 Server, Linux 2.x, and Solaris 5.9:

Table 2.1: ARP request impact on various OS

Windows

XP

Windows

2000

Windows

2003 Server

Linux 2.4

Linux 2.6

Free BSD

4.11

SunOS

Solaris5.9

Entry exist in

ARP cache?

Yes

No

Yes

No

Yes

No

Yes

No

Yes

No

Yes

No

Yes

No

ARP request














ARP reply


X




X


X


X




√ = ARP request or reply message is accepted by the system & allows the update or creation of MAC / IP entry

X = ARP request or reply message is rejected by the system & doest NOT allow update & creation MAC/IP entry

The results of the experiment indicated that:

1. If the entry does not exist in the ARP cache, all tested OS's, except Windows 2000, Free BSD 4.11 and SunOS Solaris 5.9, will not allow the creation of a new entry by an ARP reply message.

2. If the entry does not exist in the ARP cache, all tested OS's allow the creation of a new entry by an ARP request message.

3. However, if the entry existed already in the ARP cache, all tested OS's allowed its update by an ARP reply (even in the absence of an ARP request) or request message.

Therefore, when using ARP reply messages, the ARP cache poisoning attack becomes difficult to realize against most OS's. However, it remains indeed possible when using ARP request messages. In conclusion, most common OS's are still vulnerable to the ARP cache poisoning attack. Malicious users can first use ARP request messages to create fake IP/MAC entries in the ARP caches of their target hosts. Then, fake ARP reply massages are used to maintain the existence of fake IP/MAC entries in the ARP caches of the target hosts.

2.1.4 Example of ARP Cache Spoofing

As mentioned above the ARP Spoofing process is mainly to corrupt the ARP cache of any host over the network with fake IP/MAC pair in order to perform some serious attacks such as Man-in-the-Middle attack [MiM] or Denial-of-Service [DoS]. In the following demonstration we will show the two different steps before and after the ARP cache poisoning is taking place, in the (2.1) and (2.2).

2.1.4.1 ARP Cache Spoofing (before ARP corruption)

In (2.1) it's clear that the ARP cache table is legitimate for all hosts connected to the network via a switch, where we can see that every IP-address is mapped to a valid and corresponding MAC-address for that host. For instance; in ARP cache table of the host “A” ; the IP-address of the host “B” is mapped with the MAC-address of the host “B”. And the same case is applied on host “C”.

On the other hand, in ARP cache table of the host “B” for example; the IP-address of the host “A” is mapped with the MAC-address of the host “A”. And the same case is applied on host “C”.

- Let us see what changes may occur after the cache poisoning:

2.1.4.2 ARP Cache Spoofing (after corruption)

In (2.2): Host “C” is the malicious host in this scenario. It corrupted the ARP cache tables for both hosts “A” and “B”. The ARP cache table for host “A” is becoming illegitimate now, where we can see that every IP-address is mapped to an invalid and not the corresponding MAC-address for that host. For instance; in ARP cache table of the host “A” ; the IP-address of the host “B” is mapped with the MAC-address of the host “C”. And the same case is applied on host “B”.

In this case whenever the host “A” want to communicate with host “B”, the TCP/IP traffic will be guided to pass by the malicious host “C” instead of “B”..!

So what..?

Hackers use the process of generating such abnormal ARP request packets to corrupt the ARP cache for certain hosts and perform different attacks over the network (e.g. MiM or DoS).

2.1.5 Gratuitous ARP:

This process is concerned about IP address duplication attack. Such a situation is due to the case when a host sends an ARP request to look for its MAC. This may occur when the host reboots, or once changing its Ethernet Number or the IP address[17].

Gratuitous ARP is doing the following tasks:

i. Finding IP address conflicts in the Network by verifying if there is another host that has the same IP address and displaying this message:

« duplicate IP address sent from Ethernet address: a:b:c:d:e:f» .

ii. If a host changing its MAC or IP address by sending an ARP request, then it will force to update the ARP cache on the Network with the new MAC/IP address

P.S. ARP Gratuitous is mainly influence old Operation Systems, such as; Windows XP SP1 or older.

2.1.6 MiM attack:

The man-in-the-middle attack, (abbreviated as: MiM, or sometimes: MITM[18]) comes from the Packet-Sniffing[19]. MiM doesn't listen to all the packets that walk along the network as the Sniffer works, however it interfere with one or more hosts in the network and starts snooping between them. Such hosts been listened by a MiM are commonly called victims. A victim can be a normal host (e.g. PC or Notebook), gateway or even a router!

An attacker who is mainly spying between two or more victims; is establishing a autonomous connections between the victims and convey messages between them as if they are directly connected. And hence we call him: Man-in-the-Middle.

So far MiM is just listening to the traffic passing through two victims. Although this kind of outrage is illegitimate and can reach sensitive information like passwords, e-mail messages, encryption keys…etc. however it become worse and worse when he tries to go further than and inject false and fake packets and convey them between the deceived victims.

According to[20] MiM attack is classified as an active attack, because the hacker manages the traffic in the network between the source and the destinations.

MiM is very famous approach used by hackers nowadays and uses the ARP protocol in order to attack the ARP-Cache tables and hence control the targets[21]. By poisoning the ARP tables for all hosts in the network for example; will instruct the hosts to reroute the traffic to the Attacker host instead of the Gateway, where he starts interfering between any two or more victims.

One more thing needs to be mentioned that the attacker has to forward all the interrupted packets to the original destination, so that the synchronized connection will remain and doesn't time out...!

In the above ; ARP spoofing occurs when sending a fake and spoofed ARP reply to the target, i.e. if the Attacker has an IP: [10.10.1.10] and wants to sniff the traffic between the Victim who has an IP: [10.10.1.20] and the Gateway which has an IP: [10.10.1.254] it simply sends fake ARP replies to associate it's own MAC address with the Gateway IP [10.10.1.254]. The Victim then is trapped and starts sending all the packets intended to the Gateway to the Attacker address as in the above illustration.

2.1.7 Denial of Service [DoS]:

DoS attacks; occurring when any suspicious host over the network performs ARP cache poisoning and receives any packet designated to the original target to the suspicious host and cause a block in the connection between the host and the target which is being attacked. Kindly notice that more details regarding Denial of Service [DoS] will be discussed in section (3.2) in chapter No. 3.

2.2 Evaluation Of Common Intrusion Detection Systems And Intrusion Prevention Systems

2.2.1 ARP cache poisoning and MiM attacks:

The ARP cache spoofing attack and the Man-in-the-Middle attack are usually maintained and controlled by humans[22]. There are many solutions proposed in solving this type of security threat, based on different mechanisms or protocols at different OSI model layers; such as; Application layer, Network layer and Data link layer[16].

2.2.2 Detection of ARP cache poisoning attack:

Arpwatch[23] and Snort[24] are tools that are able to detect ARP cache poisoning attack by checking each packet contents. To do that, these tools monitor Ethernet activities and keep databases of Ethernet MAC/IP address pairs. If an analyzed packet has an Ethernet MAC/IP address pair, which does not appear in their databases, then the system administrator is alerted. Arpwatch and Snort are sensors that need to have access to monitoring ports on the switches (usually, known under the name of SPAN port, or mirroring port) or be placed in locations where they can see all the network traffic. Therefore, it would be more interesting and efficient to detect any ARP anomalies without the use of any access privilege or special ports on the switches. This is the case since substantial performance impact can be caused when port mirroring is in effect. This strategy makes ARP spoofing detection based on sniffing not quite viable on switched LAN networks[16].

2.2.3 Packets sniffing and MiM attacks:

On shared broadcast LAN networks, such as hubbed and wireless networks, packets sniffing can easily be achieved with minimal efforts. However, a switched LAN environment presents a different problem with few available techniques for sniffing. The first technique consists of connecting to an administrative port on the Switch and setting it to broadcast mode. The administrative port will now receive all traffic. A second technique is summarized by sending a large number of spoofed packets, which is usually an ARP packet (Address Resolution Protocol) to the Switch so it fails to open and sends all packets to all ports. However, a recent study[25] shows that only old switches models are vulnerable to this attack. Another technique, which is based on the MiM attack, is to tell target hosts on the LAN network to use an attacker's MAC address in order to get to any other host. This technique is based on the generation of malicious ARP traffic. The attacker host takes a copy of the received traffic then forwards it to the correct host.

Today, security devices, such IDS's (An intrusion detection system) [26] and IPS's (An Intrusion Prevention System)[27], have become a standard component of security solutions used to protect computing assets from hostile attacks. IDSs are able to detect many types of attacks, such as denial of service (DoS) and IP spoofing attacks. But, their ability and reliability to detect certain attacks are still questionable, notably the MiM attack. Prevention mechanisms, such as S-ARP[28] and O-ARP[29] lack efficient implementation on real systems and for a performance evaluation

2.2.4 Prevention mechanisms based on secure ARP protocols:

A number of cryptographic protocols have targeted issues related to ARP security. For example, S-ARP[28] is a popular ARP security protocol that uses asymmetric cryptography utilizing digitally signed ARP replies. At the receiving end, an entry is updated if and only if the signatures are correctly verified. S-ARP is considerably slow as can be deduced from the results presented in[28]. Furthermore, S-ARP can not prevent against cache poisoning attacks.

a. O-ARP technique:

O-ARP[29] is a secure ARP technique that is similar to S-ARP with regards to its message format and key management. However, it uses cryptography only when necessary and tries to avoid it when ever possible. The authors in[29] claim that O-ARP is much faster than S-ARP on the average, and can be used as security measure to prevent against cache poisoning attacks. Meanwhile, the authors did not implement O-ARP in any operating system to obtain measurements for its performance.

In[30] the authors proposed another Secure Address Resolution Protocol. In this protocol, a secure server shares secret keys with each host on a subnet. The server maintains a database of MAC/IP address mappings, which is updated periodically through communication with each host. All ARP requests and replies occur between a host and the server, and replies are authenticated using the shared pair keys. The main drawback of this technique is congestion at the server, which constitutes a single point of failure in the network.

b. Ticket-based Address Resolution Protocol

Ticket-based Address Resolution Protocol (TARP)[31] is another secure ARP protocol. TARP is built as an extension to ARP. TARP implements security by distributing centrally issued secure MAC/IP address mapping attestations through existing ARP messages. These attestations, called tickets are given to clients as they join the network and are subsequently distributed through existing ARP messages. Unlike other popular ARP-based solutions, the costs per resolution are reduced to one public key validation per request/reply pair in the worst case. However, networks implementing TARP are vulnerable to two types of attacks-active host impersonation, and DoS through ticket flooding. In addition, TARP does not include support for dynamic environments, mainly when host's IP addresses changes dynamically.

c. Cryptographic Technique

Another approach was presented in[32], where the authors proposed a cryptographic technique. The technique is based on the combination of digital signatures and one time passwords based on hash chains.

d. ARPSec protocol

Moreover, in[33], the ARPSec protocol was proposed as an ARP security extension that intends to solve the security weaknesses of the ARP protocol. ARPSec provides an anti-replay protection and authentication using a secret key shared only by the source and the destination of the packet computed by an authenticated Diffie-Hellman exchange. Unfortunately, no real-time implementation or performance evaluations on actual network systems were performed to quantify their efficiency.

At the network layer, the IPSec[34] protocol can be used to facilitate the confidentiality, integrity, and authentication of information communicated using the IP protocol. IPSec proposes solutions for many security issues within the IP protocol, but does not prevent any malicious users from manipulating ARP packets, at the Data link layer, or redirecting target network IP traffic to other destinations. IPSec guaranties the confidentiality and integrity of the redirected IP traffic, but cannot prevent malicious users from causing DoS attacks on target hosts.

2.2.5 Protection mechanisms at the Application layer:

Recently, several security protection mechanisms have been proposed at the Application layer. However, such mechanisms might not be effective against certain attacks at the lower layers, mainly at the Data Link layer. For example, in[35], the authors argued that most deployed user authentication mechanisms fail to provide protection against the MiM attack, even when they run on top of the SSL/TLS protocol or other similar protocols. The authors then introduced the notion of SSL/TLS session-aware user authentication, and elaborated on possibilities to implement it. Another example is the Interlock protocol, proposed in[36], which was later shown to be vulnerable to attacks when used for authentication[37]. For enhanced security at the Application layer, in[38] a new proposed technique called Delayed Password Disclosure (DPD) was shown to complement a password-based authentication and key exchange protocol to protect against a special form of the MiM attack, the doppelganger window attack. On the other hand, in[39] the authors proposed the notion of a Password Protection Module (PPM) that provides protection against the MiM attack for certain situations. PPMs are effective only if they take into account network-related information, such as IP addresses and URLs. This makes PPMs very difficult to deploy and manage. Additional protection mechanisms were proposed in[40] to secure tunneled authentication protocols against the MiM attack. In most cases, prevention mechanisms at the Application layer guarantee the confidentiality and integrity of the traffic exchanged but do not prevent malicious users from redirecting network traffic to their hosts.

2.2.6 External protection mechanisms:

Several attempts have been made to address the above security issues through methods external to the ARP protocol. For example, it has been proposed that hosts can statically be cond[41] . This would incur a huge administrative overhead and is largely intractable for dynamic environments. Conversely, the port security[42] features available in recent switches restrict the use of physical ports to con MAC addresses. If an attacker forges its own MAC address and includes an additional frame header containing malicious mapping, poisoning a victim's ARP cache can still be possible. This approach only prevents certain kinds of MAC hijacking, but does nothing to prevent MiM attack. Hence, it is only a partial and in many ways limited solution

CHAPTER 3

REAL-TIME DETECTION TECHNIQUE

There are numerous expensive Network Intrusion Protection Systems and Intrusion Detection Systems [IPS/IDS]. Such Hardware appliances or tools which are available in the market are expensive too and their manufacturers claim that their solution can handle the ARP Spoofing. In our research we evaluated the most renowned and common security solutions and experiment the competence for ARP Spoofing detection.

In our analysis we performed extensive experiments in the Networking and Communication Lab at College of Information Technology in UAE-University for detecting ARP Spoofing. Obviously ARP Spoofing was not considered significantly by the security solutions we studied, despite the fact ARP Spoofing is a serious danger upon networks while it is simple to execute. (Kindly refer to chapter 2: ARP Spoofing)

The experiments show what those detection and protection appliances or tools are not fully robust against ARP Spoofing attacks. In Experiment section underneath, table 4: shows the performance of the security Appliances against 10 different ARP Spoofing attacks. Thus, and as a solution for this “flaw” in these systems we proposed an optimal algorithm which can be implemented in any security solution as a real-time detection technique in order to detect ARP Spoofing attacks. This research was reported a new finding which was published in December 15th 2009 on IEEE Xplore[43].

In the following sections; we will discuss how we conducted a fake ARP Spoofing attacks (10 types) and experiment them on the Security Solutions which are dealing with Intrusions in the network. Then; analyzing the result of the experiments. And finally proposing the new real-time detection technique

3.1 ARP spoofing

ARP spoofing, also called ARP Cache poisoning, introduces a forged IP address to MAC address mapping in another host's ARP cache. The ARP poisoning can be done by updating an existing ARP entry or inserting new forged entry in the ARP cache for a target host. There are two ways to do ARP poisoning, the first one is adding a forged entry in the ARP cache of the target host, and the second one is updating an existing entry with a forged IP address or MAC address.

§ Adding a new forged entry: an ARP request message with forged source IP and MAC addresses in the ARP header will be sent to the target host and when the host is receiving the ARP request message, it assume a connection will be established between the source and the host, so it creates a new ARP entry in the ARP-cache. As a result to this the ARP-cache of the host will become corrupted with a forged IP and MAC addresses.

§ Update an ARP-cache with a forged entry: although the IP and MAC addresses of the host are registered in the ARP-cache entries, it can be updated again by sending the forged IP and MAC again to the host target.

3.2 ARP spoofing based MiM and DoS attacks

Man-in-the-Middle attacks [MiM] and Denial of Service attacks [DoS] are mostly familiar in Local Area Networks, they are easy to launch as well.

When the malicious host re-forwarding the network traffic between the target hosts and is enabling IP Packet routing and starts sniffing the network; then MiM is taking place. The malicious host in this case is becoming similar to a router where it redirects all the traffic without any interruption. ( 3.1).

It is important to notice that if the malicious host corrupts the ARP caches of the two target hosts without enabling its IP packet routing, then the two hosts will not be able to exchange packets and it will be a Denial of Service (DoS) attack. This is extremely harmful while considering routers and gateways can be poisoned too. To perform MiM attack, host C enables its IP packet routing and corrupts the ARP caches of hosts A and B, using ARP cache poisoning attack.

However, in DoS attack ( 3.2), target hosts are denied from communicating with each other, or with the Internet. This is done simply by corrupting their ARP caches with fake entries including nonexistent MAC addresses, or by disabling the IP packet routing option in the malicious host, so that received redirected traffic will not be forwarded to its real destination.

3.3 Abnormal ARP Packets

ARP spoofing uses abnormal ARP packets to corrupt ARP caches of target hosts. The detection process consists of detecting those abnormal ARP packets sent over the LAN network. However, most abnormal ARP packets do not damage the ARP caches (Tables 1 and 2), but they may produce DoS situations in target hosts. Consequently they should be detected. Tables 1 and 2 identify two lists of all possible abnormal ARP request and reply packets, respectively. We identified 4 possible types of abnormal ARP request packets and 6 possible types of abnormal ARP reply packets, as follows:

P#1, P#5, and P#7: Security devices should keep track of IP-to-MAC address mappings. Every ARP packet contains a mapping of IP-to-MAC address. ARP requests contain the IP-MAC mapping of the sender. ARP replies contain the IP-MAC mapping of the machine resolved. Every mapping is inserted into a database. If a mappings is monitored that breaks current mappings, an alert is generated. IP-to-MAC mappings database can filled either automatically or manually.

P#2, P#6, and P#8: ARP packets have special restrictions. In an ARP request and reply packet, the Ethernet source MAC address has to match the ARP source MAC address. In ARP reply, the Ethernet destination MAC address has to match the ARP destination MAC address.

P#3: A normal ARP request needs to be sent to the broadcast MAC address, and not to a Unicast MAC address. Such packets are used by ARP spoofing software to spoof only a specific machine and not all machines on a network.

P#9: A normal ARP reply needs to be sent to Unicast MAC address, and not the broadcast MAC address. Such packets are used by ARP spoofing software to spoof only a specific machine and not all machines on a network.

P#4 and P#10: There are fields in the ARP packet that have restrictions regarding the values they can adopt. This module checks these values for correctness. ARP mappings may not contain certain IP addresses. These include broadcast and multicast as well as null addresses.

Moreover, some MAC addresses in ARP packets are highly suspicious. No IP-to-MAC mapping should, for example, have the MAC broadcast, multicast or null address assigned. Every ARP packets IP addresses need to be in the same subnet. An ARP packet with IP addresses that are not in the network interfaces cond subnet are suspicious and will be alerted.

Tables 3.1 and 3.2 shows that; only the abnormal packets P#1 and P#5 can corrupt ARP cache of target hosts with a fake IP-MAC entries. The remaining abnormal ARP packets do not corrupt ARP caches. However, they may still be harmful and should be detected since they can carry DoS attacks.

Table 3.1: List of possible abnormal ARP request packets

Packet number

P#1

P#2

P#3

Unicast ARP

request

P#4

Unexpected IP or MAC address in ARP request packets

ARP Header

ARP Operation

1

1

1

1

Source IP

IP_A

IP_A

0.0.0.0

255.255.255.255

Multicast

Not in the network subnet

Source MAC

MAC_X

MAC_A

00-00-00-00-00-00

ff-ff-ff-ff-ff-ff

Multicast

Destination IP

0.0.0.0

255.255.255.255

Multicast

Not in the network subnet

Destination MAC

Ethernet Header

Source MAC

MAC_X

00-00-00-00-00-00

ff-ff-ff-ff-ff-ff

Multicast MAC

Destination MAC

Unicast

00-00-00-00-00-00

Unicast or Multicast

Does the packet corrupt the ARP cache?

Yes

No

No

No

IP_A: is the IP address of a host A; MAC_A: is the MAC address of a host A ; MAC_X: is a MAC address of a nonexistent host; Unexpected IP or MAC address in ARP request packets

Table 3.2: List of possible abnormal ARP reply packets

Packet number

P#5

P#6

P#7

P#8

P#9

Broadcast

ARP reply

P#10

Unexpected IP or MAC address

ARP Header

Operation

2

2

2

2

2

2

Source IP

IP_A

IP_A

0.0.0.0

255.255.255.255

Multicast Not in

the network subnet

Source MAC

MAC_X

MAC_A

00-00-00-00-00-00

ff-ff-ff-ff-ff-ff

Multicast

Destination IP

IP_B

IP_B

0.0.0.0

255.255.255.255

Multicast Not in

the network subnet

Destination

MAC

MAC_X

MAC_B

00-00-00-00-00-00

ff-ff-ff-ff-ff-ff

Multicast

Ethernet Header

Source MAC

MAC_X

00-00-00-00-00-00

ff-ff-ff-ff-ff-ff

Multicast

Destination

MAC

MAC_X

ff-ff-ff-ff-ff-ff

00-00-00-00-00-00

ff-ff-ff-ff-ff-ff

Multicast

Does the

packet corrupt ARP cache?

Yes

No

No

No

No

No

IP_B: is the IP address of a host B; MAC_B: is the MAC address of a host B; Unexpected IP or MAC address in ARP reply packets.

3.4 Experiments

The security solutions which are used in the experiments are classified into 4 categories:

1. LAN switches

a. Cisco switch 3560 Series

b. Juniper Switches EX3200 Series

2. Software IDS/IPS

a. Snort IDS

b. XArp 2 tool

c. Sax2 NIDS

3. IDS/IPS hardware appliances

a. Cisco IPS 4255 Series

b. TopLayer Model 5000

c. IBM ISS Proventia Model GX4004C

d. SourceFire

e. TippingPoint 50

4. Unified Threat Management (UTM) devices

a. Juniper Netscreen 50

Table 3.3 shows the identified security solutions that perform ARP inspection on ARP packets regardless of the type of inspection.

Table 3.3: Security solutions performing ARP inspection

Security solutions

Type

Performing ARP inspection

(Yes or No)?

Detection or prevention solution?

Cisco Switch 3560 Series

Switch

Yes

Prevention

Juniper Switches EX3200 Series

Switch

Yes

Prevention

Snort IDS

IDS software tool

Yes

Detection

XArp 2 tool

IDS software tool

Yes

Detection

Sax2 NIDS

IDS software tool

Yes

Detection

Cisco IPS 4425 Series

IPS appliance

Yes

Detection

TopLayer Model 5000

IPS appliance

No

Detection

IBM ISS Proventia

Model GX4004C

IPS appliance

No

Detection

SourceFire

IPS appliance

No

Detection

TippingPoint 50

IPS appliance

Yes

Detection

Juniper Netscreen 50

UTM

No

Detection

In the experiments, we excluded from the above list, the IPS TippingPoint 50 since it includes ARP inspection that is not concerned with the detection of ARP spoofing attack. Among the security solutions that include ARP inspection mechanisms (Table 3.3), Table 3.4 shows the ones that can totally or partially detect the abnormal ARP packets listed in Tables 3.1 and 3.2.

Table 3.4: Detection of abnormal ARP request and reply packets

P#1

P#2

P#3

P#4

P#5

P#6

P#7

P#8

P#9

P#10

Cisco Switch 3560 Series

D

D

N/D

N/D

D

D

D

D

N/D

N/D

Juniper Switches EX3200

D

D

N/D

N/D

D

D

D

D

N/D

N/D

Snort IDS

D

D

D

N/D

D

D

D

D

N/D

N/D

XArp 2 tool

D

D

D

Partially

D

D

D

D

D

Partially

Sax2 NIDS

N/D

N/D

N/D

N/D

N/D

N/D

N/D

N/D

N/D

N/D

Cisco IPS Series 4255

D

N/D

N/D

Partially

D

N/D

D

N/D

N/D

Partially

D: for detection, N/D: for not detection, Partially: for partial detected

Using the data in Table 3.4, we can easily notice that no system offers an ideal solution for the problem of ARP spoofing detection. Out of the detection systems, the XArp 2 tool seems ideal in terms of the number of detected abnormal ARP packets. Snort IDS seems to be a good alternative, but both of them perform only detection and are not enable to prevent ARP spoofing attack. The prevention/blocking systems, such as Cisco switches 3560 Series[44] or Juniper switches EX3200 Series[45], are the most ambitious ones, but require usually complex installations. In addition, the high costs of these switches make this solution prohibitive for many companies[46]. Cisco IPS is a prevention system and is a limited alternative solution since it can deal with few types of abnormal ARP packets (P1 and P5). Nevertheless, it is important to remember that the packets P#1 and P#5 are the most used ARP packets during ARP spoofing, since they are the only packets that can corrupt the ARP caches of target hosts.

Sax2 NIDS cannot detect any abnormal packet described in Tables 3.1 and 3.2. However, it can detect ARP request storm traffic and ARP scanning traffic.

3.5 Cross-layers ARP inspection

In order to be able to detect the abnormal ARP packets for instance; P#2, P#6, and P#8 described in Tables 3.1 and 3.2, a security solution requires including an ARP inspection mechanism that can perform cross-layers ARP inspection between the Ethernet and ARP headers as in 3.3. In an ARP request and reply packet, the Ethernet source MAC address has to match the ARP source MAC address [43]. However, in ARP reply, the Ethernet destination MAC address has to match the ARP destination MAC address, 3.4 shows the two cases of performing ARP cross-layer checking for ARP request and ARP reply

ARP header

Operation =1/2 (request, reply)

Source IP = Tester IP

Source MAC = Tester MAC

Destination IP = Target Host IP

Destination MAC = 00-00-00-00-00-00

Ethernet header

Source MAC = Tester MAC

Destination MAC = Target MAC

(Broadcast=request, Unicast=reply)

Ethernet Type = 0x0806 (ARP)

Hardware Type = 1 (Ethernet)

Protocol Type = 0x0800 (IP)

Ethernet source MAC à match ARP source MAC

ARP Reply:

Ethernet destination MAC à match ARP destination MAC

Moh'd Al-Hemairy - 6 - M.Sc. thesis, Informatics BUiD

3.6 ARP Statefull inspection

ARP replies should normally follow ARP requests[43]. A statefull detection process should remember all ARP requests originating and match them to ARP replies. Many ARP spoofing tools send ARP replies that are not requested. Table 3.5 shows the list of security solutions that perform ARP statefull inspection on ARP requests against ARP replies. ARP inspection mechanism might give false positives in some cases as machines want to distribute their IP-to-MAC mapping to other machines that did not request it. Among the above tested security solutions, XArp 2 tool and Sax2 IDS are the only solutions that perform ARP statefull inspection

Table 3.5: Security solutions including ARP statefull inspection

Security Solution type

Performing ARP

stateful inspection?

Cisco Switch 3560 Series

No

Juniper Switches EX3200 Series

No

Snort IDS

No

XArp 2 tool

Yes

Sax2 IDS

Yes

Cisco IPS 4425 Series

No

3.7 ARP request Storm and ARP Scan

ARP request storm: when the Dynamic ARP entries remain in the ARP cache for few minutes then they are removed if they are referenced. Consequently, to keep the ARP cache of a target host corrupted with fake entries, malicious users may storm the target host with ARP request packets. In other words, the malicious host keeps sending continuously fake ARP request packets to the target host. If the number of ARP request packets per second exceeds the ARP request threshold, then this is an indication that an ARP request storm is taking place. Table 3.6 shows the security solutions that include mechanisms to detect ARP request storm and/or ARP scanning. Among the above tested security solutions, Sax2 IDS is the only solution that is able to detect ARP request storm and ARP scanning.

ARP scan: The possible reason of ARP scanning in LAN networks is surveillance software running, host infected with virus, or the virus is doing ARP scanning.

Table 3.6: Security solutions with ARP request storm and ARP scan detection mechanisms

Detect ARP Request Storm?

Detect ARP Scan?

Cisco Switch 3560 Series

No

No

Juniper Switches

EX3200 Series

No

No

Snort IDS

No

No

XArp 2 tool

No

No

Sax2 IDS

Yes

Yes

Cisco IPS 4425 Series

No

No

3.8 Experiments' Results Analysis

The experiments in this work show clearly that ARP spoofing is not fully detected by most common security solutions. This is because of the absence of an efficient ARP spoofing detection algorithm. There are abnormal ARP packets that do not corrupt ARP caches. However, they are still harmful and should be detected, since they can carry DoS attacks.

In addition to detecting some abnormal ARP packets such as P#2, P#6 and P#8, cross-layer ARP inspection is required. Among the tested security solutions, only Cisco switch 3560 Series, Juniper switch EX3200 Series, Snort IDS, and XArp 2 tool perform cross-layers ARP inspection.

Security solutions should also be able to cope with ARP request storm traffic and ARP scanning traffic. This type of traffic is used usually to keep target hosts' ARP caches corrupted or produce DoS attack. Sax2 IDS is the only security solution that is able to detect ARP request storm and ARP scanning.

According to the conducted experimental results, XArp 2 tool is the most efficient available security solutions to cope with ARP spoofing. However, it needs minor improvement, compared to the other tested security solutions, by adding mechanisms to detect ARP request storm and ARP scanning. 3.5 shows a LAN network that uses a simple switch without any security features and a host running XArp 2 tool to detect ARP spoofing attack. The host running XArp 2 tool is connected to a SPAN port (mirroring port) in order to be able to receive and analyze all the LAN network traffic. This network architecture is considered ideal in terms of its low cost and its efficiency regarding the detection of ARP spoofing. However, this network architecture cannot prevent ARP spoofing, unless the simple switch is replaced by a more costly switch that integrates advanced security features. Cisco switch 3560 Series[44] and Juniper switch EX3200 Series[45] are examples of highly cost switches that can prevent ARP spoofing using a feature called Dynamic ARP Inspection (DAI).

3.9 Optimal ARP Spoofing Detection Algorithm

Based on the experiments results, it is concluded that any security system claiming to cope with ARP spoofing, should use an efficient algorithm. We compiled six requirements that any Security analyst should follow in order to get an ideal algorithm that deals with ARP spoofing on switched LANs.

Requirements of ideal ARP Spoofing Detection Algorithm

§ Perform a cross-layer ARP inspection between the Ethernet and ARP layers

§ Perform ARP statefull inspection

§ Detect non expected IP and MAC addresses

§ Detect ARP storm

§ Detect ARP scanning

§ Build manually (in case of non DHCP environment) or automatically (in case of DHCP environment) IP-MAC mapping table, in order to be able to detect invalid IP-MAC pairs.

The following is the algorithm that was proposed in order to detect ARP Spoofing, presented in (3.6):

Abnormal_Arp_Packet_Detection (Ethernet_header, ARP_header, IP_MAC_Mapping_Table)

{ /* ARP request packet */

if (ARP_Operation = “request”):

{ Unicast_ARP_request (Ethernet_MAC_Destination); /* for detecting packet P#3 */

Unexpected_IP_MAC_Addresses_in_ARP_Request (Ethernet_MAC_Source, Ethernet_MAC_Destination, ARP_IP_Source, ARP_MAC_Source, ARP_IP_Destination, ARP_MAC_Destination);

/* for detecting packet P#4 */

Cross_Layer_Inspection_ARP_Request (Ethernet_MAC_Source, ARP_MAC_Source)

/* for detecting packet P#2 */

IP_to_MAC_Address_Mappings_ARP_Request (ARP_IP_Source, ARP_MAC_Source, IP_MAC_Mapping_Table )

/* for detecting packet P#1 */ }

/* ARP reply packet */

if (ARP_Operation = “reply”):

{ Broadcast_ARP_reply (Ethernet_MAC_Destination)

/* for detecting packet P#9 */

Unexpected_IP_MAC_Addresses_in_ARP_Reply (Ethernet_MAC_Source, Ethernet_MAC_Destination, ARP_IP_Source, ARP_MAC_Source, ARP_IP_Destination, ARP_MAC_Destination); /* for detecting packet P#10 */

Cross_Layer_Inspection_ARP_Reply (Ethernet_MAC_Source, ARP_MAC_Source, Ethernet_MAC_Destination, ARP_MAC_Destination )

/* for detecting packets P#6 and P#8 */

IP_to_MAC_Address_Mappings_ARP_Reply (ARP_IP_Source, ARP_MAC_Source, ARP_IP_Destination, ARP_MAC_Destination, IP_MAC_Mapping_Table )

/* for detecting packets P#5 and P#7 */

}}

- imagine the IP_MAC_Mapping_Table to looks like the following table; where IP address in the row (i) and column (j) is represented by [IPi,j]and is mapped with the corresponding MAC in the row (i) and column (j), which is also represented by [MACi,j]. the 3.7 is showing how this mapping is matches:

i/j

j

i

IP Address

MAC Address

IP 1,1

MAC 1,2

IP 2,1

MAC 2,2

IP i,j

MAC i,j

Fig. 3.7: Mapping table between IP-address and MAC-address

3.9.1 Sample of the code implemented in C++ language:

In the following (3.8) we will shows part of the code implemented in C++ based on the algorithms that was presented in (3.6). It has been written in C++ language in order to test it in the LAB for detecting ARP Spoofed & Abnormal packets and to ensure that all known types of ARP Spoofing attacks are addressed and detected by the security solution. Section 3.9.3 shows the testing experiment:

Abnormal_Arp_Packet_Detection (Ethernet_header, ARP_header, IP_MAC_Mapping_Table)

{ /* ARP request packet */

if (ARP_Operation = “request”);

{

IP_to_MAC_Address_Mappings_ARP_Request (ARP_IP_Source, ARP_MAC_Source, IP_MAC_Mapping_Table )

{ for i > 0 , j > 0 , i ++ , j ++;

if (ARP_IP_Source = IP_MAC_Mapping_Table [i,j]) ;

AND if (ARP_MAC_Source = IP_MAC_Mapping_Table [i,j] ) ;

then Print (“This ARP packet is valid”) ;

else Print (“This packet is spoofed & rejected; Case #1”) ;

} /* for detecting packet P#1 */

Cross_Layer_Inspection_ARP_Request (Ethernet_MAC_Source, ARP_MAC_Source)

{ for i > 0 , j > 0 , i ++ , j ++;

if (ARP_IP_Source = IP_MAC_Mapping_Table [i,j]) ;

else if (ARP_MAC_Source = Ethernet_MAC_Source [i,j] ) ;

then Print (“This ARP packet is valid”) ;

else Print (“This packet is spoofed & rejected; Case #2”) ;

} /* for detecting packet P#2 */

Unicast_ARP_request (Ethernet_MAC_Destination);

{ for i > 0 , j > 0 , i ++ , j ++;

if (Ethernet_MAC_Destination = “00-00-00-00-00-00”) ; /* check for broadcast*/

then Print (“This ARP packet is valid”) ;

else Print (“This packet is spoofed & rejected; Case #3”) ;

} /* for detecting packet P#3 */

Unexpected_IP_MAC_Addresses_in_ARP_Request (Ethernet_MAC_Source, Ethernet_MAC_Destination, ARP_IP_Source, ARP_MAC_Source, ARP_IP_Destination, ARP_MAC_Destination);

{ for i > 0 , j > 0 , i ++ , j ++;

if (Ethernet_MAC_Source = ARP_MAC_Source [i,j]) ;

else if (Ethernet_MAC_Destination = ARP_MAC_Destination [i,j] ) ;

else if (ARP_IP_Source =! “0.0.0.0”) ; /* IP_Source should not be broadcast */

else if (ARP_IP_Source =! “0.0.0.0”) ; /* IP_Source should not be broadcast */

else if (Ethernet_MAC_Destination = “00-00-00-00-00-00”) ; /*check for broadcast*/

then Print (“This ARP packet is valid”) ;

else Print (“This packet is spoofed & rejected; Case #2”) ;

} /* for detecting packet P#4 */

}

Abnormal_Arp_Packet_Detection (Ethernet_header, ARP_header, IP_MAC_Mapping_Table)

/* ARP reply packet */

if (ARP_Operation = “reply”);

{

IP_to_MAC_Address_Mappings_ARP_Reply (ARP_IP_Source, ARP_MAC_Source, ARP_IP_Destination, ARP_MAC_Destination, IP_MAC_Mapping_Table );

IP_to_MAC_Address_Mappings_ARP_Request (ARP_IP_Source, ARP_MAC_Source, IP_MAC_Mapping_Table ) /* for detecting packets P#5 and P#7 */

{ for i > 0 , j > 0 , i ++ , j ++;

if (ARP_IP_Source = IP_MAC_Mapping_Table [i,j]) ;

AND if (ARP_MAC_Source = IP_MAC_Mapping_Table [i,j] ) ;

then Print (“This ARP packet is valid”) ;

else Print (“This packet is spoofed & rejected; Case #5”) ;

} /* for detecting packet P#5 */

{ for i > 0 , j > 0 , i ++ , j ++;

if (ARP_IP_Destination = IP_MAC_Mapping_Table [i,j]) ;

AND if (ARP_MAC_Destination = IP_MAC_Mapping_Table [i,j] ) ;

then Print (“This ARP packet is valid”) ;

else Print (“This packet is spoofed & rejected; Case #7”) ;

} /* for detecting packet P#7 */

Cross_Layer_Inspection_ARP_Reply (Ethernet_MAC_Source, ARP_MAC_Source, Ethernet_MAC_Destination, ARP_MAC_Destination ) /* for detecting packets P#6 and P#8 */

{ for i > 0 , j > 0 , i ++ , j ++;

if (ARP_MAC_Source = IP_MAC_Mapping_Table [i,j]) ;

AND if (ARP_MAC_Source = Ethernet_MAC_Source [i,j] ) ;

then Print (“This ARP packet is valid”) ;

else Print (“This packet is spoofed & rejected; Case #6”) ;

} /* for detecting packet P#6 */

{ for i > 0 , j > 0 , i ++ , j ++;

if (ARP_MAC_Destination = IP_MAC_Mapping_Table [i,j]) ;

AND if (ARP_MAC_Destination = Ethernet_MAC_Destination [i,j] ) ;

then Print (“This ARP packet is valid”) ;

else Print (“This packet is spoofed & rejected; Case #6”) ;

} /* for detecting packet P#8 */

Broadcast_ARP_reply (Ethernet_MAC_Destination) /* ARP reply should be Unicast */

{ for i > 0 , j > 0 , i ++ , j ++;

if (Ethernet_MAC_Destination = “00-00-00-00-00-00”) ; /* check for broadcast*/

then Print (“This packet is spoofed & rejected; Case #3”) ;

else Print (“This ARP packet is valid”) ;

} /* for detecting packet P#9 */

Unexpected_IP_MAC_Addresses_in_ARP_Reply (Ethernet_MAC_Source, Ethernet_MAC_Destination, ARP_IP_Source, ARP_MAC_Source, ARP_IP_Destination, ARP_MAC_Destination); /* for detecting packet P#10 */

{ for i > 0 , j > 0 , i ++ , j ++;

if (Ethernet_MAC_Source = ARP_MAC_Source [i,j]) ;

else if (Ethernet_MAC_Destination = ARP_MAC_Destination [i,j] ) ;

else if (ARP_IP_Source =! “0.0.0.0”) ; /* IP_Source should not be broadcast */

else if (ARP_IP_Source =! “0.0.0.0”) ; /* IP_Source should not be broadcast */

else if (Ethernet_MAC_Destination =! “00-00-00-00-00-00”) ; /*check for Unicast*/

then Print (“This ARP packet is valid”) ;

else Print (“This packet is spoofed & rejected; Case #10”) ;

} /* for detecting packet P#10 */

}

}

3.9.2 Testing and evaluation of the Algorithm

The code was tested in the LAB by building up a model to simulate the normal scenario for filtering any ARP spoofed packets in a network. It was implemented in order to discover or detect the 10 types of ARP abnormal (spoofed) packets {P#1, P#2.…P#10} which was shown in Table 3.1and Table 3.2.

As it was demonstrated in (3.9), we used the following items:

* Two host computers, one for sending the abnormal ARP packets (Tester), and the other for receiving the filtered ARP packets after being filtered (Target)

* A workstation PC with two Network-cards connecting the workstation with the two hosts; Tester (NIC#1 and Target (NIC#2). The workstation will be simulating a Network switch and filters the upcoming ARP traffic from the Tester-host. The proposed algorithm was implanted in the Workstation using C++ programming language and testing the input traffic coming from the abnormal traffic generator (Tester Host) via NIC#1, filtered by the algorithm, and forward the ONLY normal traffic to the destination (Target Host) via NIC#2.

* Packet Generator, in order to generate the 10 different types of the ARP abnormal packets and send them from the Tester-host to the Target-host. However we used a Software packet generator installed in the Tester-host to generate the required packets for easiness. This software is called: FrameIP and is available as a Freeware[47].

* The proposed algorithm was implemented by an object-oriented language: C++ code and installed in the Workstation to perform the filtering over the ARP traffic

3.9.2.1 Results of the test experiment

The Algorithm was successful in filtering all so far known types of ARP spoofed packets (Abnormal). Only normal ARP traffic was forwarded to the destination (Target Host) and abnormal ARP packets were dropped from the traffic. On the other hand; the network performance was not considerably affected after applying the algorithm. This is due to the fact that ARP packets have no data and are too small in size compared to TCP/IP packets.

3.9.3 Lab work

3.9.3.1 Packet Generation using FrameIP Tool

The objective of this lab is to send multiple types of packets such as; ARP, IP, TCP, UDP and ICMP to a certain host. We'll create a fake (spoofed) and malicious traffic through the network that can be possibly carrying attacks. This will help us generally to test any security device or algorithm, such as Firewall, Intrusion Detection System [IDS], Intrusion Protection System [IPS], Firewall and even Anti-sniffer.

Initially, we need to download the FrameIP from [47] to any folder in the PC then install the WinpCap from [48] which was used to capture the Packet and monitor the network, herewith the FrameIP run in 3.10, however the FrameIP commands and help is in the Appendix [2].

- We need also to use a sniffer tool installed on the source traffic generator, to verify that the generated traffic has been sent correctly. So we will use; CommView sniffer tool [49].

Now we will show an example of how an ARP request packet is generated using FrameIP tool:

- First consider the following ARP request table 3.7:

Table 3.7: ARP request details

ARP header

Operation = 1 (request)

Source IP = 172.22.0.180

Source MAC = 00-90-4B-89-AA-91

Destination IP = 20.20.20.20

Destination MAC = 00-00-00-00-00-00

Ethernet header

Source MAC = 00-90-4B-89-AA-91

Destination MAC = FF.FF.FF.FF.FF.FF (Broadcast)

Ethernet Type = 0x0806 (ARP)

- In order to send an ARP request packet, we need to collect the MAC address of the destination IP, we will use the following FrameIP command with help of Table 3.7 :

C:>FramIP -interface 2 -MAC_Type 2054 -ARP_IP_Destination 20.20.20.20

Where, interface 2; is the Wireless LAN network.

- Now we will send an ARP reply packet to a destination IP, and provide the required MAC address and IP address:

Table 3.8: ARP reply details

ARP header

Operation = 2 (reply)

Source IP = 172.22.0.180

Source MAC = 00-90-4B-89-AA-91

Destination IP = 20.20.20.20

Destination MAC = 00-17-A4-D7-D7-60

Ethernet header

Source MAC = 00-90-4B-89-AA-91

Destination MAC = 00-17-A4-D7-D7-60 (Unicast)

Ethernet Type = 0x0806 (ARP)

- The above ARP reply packet (Table 3.8) can be implemented by the following FrameIP command;

C:>FramIP -interface 2 -MAC_Type 2054 -ARP_OpCode 2 - IP_Destination 20.20.20.20 -ARP_MAC_Source 00-90-4B-89-AA-91 -MAC_IP_Source 172.22.0.180

- To send an abnormal ARP packet, we can for instance, use the broadcast MAC address for the source host in the reply ARP message, as follows;

C:>FramIP -interface 2 -send_mode 1-mac_type 2054 -arp_mac_source FF-FF-FF-FF-FF-FF -arp_ip_destination 20.20.20.20 -loops 0 -wait 0

P.S. where “FF-FF-FF-FF-FF-FF” is the broadcast MAC address, “-loops 0” means NO stop,

“-wait 0”; stand for don't wait between sending two ARP packets. And for more details about FrameIP commands you may refer to the Manual in Appendix[2].

3.9.3.2 Detecting Fake ARP packets using Snort IDS

Snort[24] is an open source network intrusion prevention and detection system (IDS/IPS). It combines the signature, protocol and anomaly-based inspection, it is also considered as the most widely deployed IDS/IPS technology in Information Security area nowadays. The good to mention Snort became the de-facto standard for intrusion prevention system because of the huge number of download and registered users.

Now we are going to demonstrate the second lab about: “Detecting fake ARP packets using Snort IDS”, the aim of this lab is to use Snort IDS to detect spoofed ARP packets, which may be used to perform MiM attack or DoS attacks.

The Snort IDS S/W should be installed on a machine which is must be connected to a SPAN port on the switch (as shown in 3.11). we will try to send about 6 types of fake ARP packets from the source (Host A) as broadcast or unicast through the network and Host C where the Snort IDS is installed will be tested against detecting the fake packets.

There are 3 hosts connected to the network switch (Host A, Host B and Host C). One host is connected to the Span port (Host C) as in the following configuration:

Configuration Phase:

1. Install Snort and WinPcap on host C

2. Unzip the file “rules” in the folder: “C:\Snort\rules”

3. Create the folder: “C:\Snort\Precproc_rules” , and put the file: “Preprocessor.rules” in the same folder

4. Con the file “Snort.Conf” which is located in “C:\Snort\etc\”.

5. Specify the correct mapping between IP and MAC addresses of the hosts connected to the switch within the "Snort.cnfig" file as shown below

6. Identify the interface and run Snort as a sniffer and as IDs.

7. Send Fake ARP packets and check the detection on the log and we use CommView sniffer to see the captured traffic through the SPAN port.

Packet#1: (Sender: Host A)

We sent this packet from Host A which is an ARP request to C MAC destination "Unicast", which is abnormal because it must be broadcast.

Detecting Result:

This is the log file shows that the snort detects the above fake ARP packet

This packet captured by host C which shows the following:

Packet#2: (Sender: Host A)

We sent a request packet from Host A to Host C, claiming that the sender is B, to assign the A's MAC to B's IP, so later if the Host C send packets to Host B, it will go to host A not B, and that is abnormal.

Detecting Result:

This is the log file shows that the snort detects the above fake ARP packet

This packet captured by host C which shows the following:

Packet#3: (Sender: Host B)

We sent this packet from Host B which is an ARP reply with the broadcast MAC destination, which is abnormal, and there is a mismatch in the MAC address of the destination in the Ethernet layer and ARP layer:

Detecting Result:

This is the log file shows that the snort detects the above fake ARP packet:

This packet captured by host C which shows the following:

Packet#4: (Sender: Host C )

We sent this packet from Host C which is an ARP request but it shows in the ARP layer that it's from A

Detecting Result:

This is the log file shows that the snort detects the above fake ARP packet

This packet captured by host C which shows the following:

Packet#5: (Sender: Host A)

We sent this packet from Host A to Host C, but there is mismatch on the destination MAC address of ARP layer and Ethernet layer which is abnormal packet

Detecting Result:

This is the log file shows that the snort detects the above fake ARP packet

This packet captured by host C which shows the following:

Packet#6: (Sender: Host A )

We sent this packet from Host A to Host C, but there is mismatch on the destination MAC address of ARP layer and Ethernet layer which is abnormal packet

Detecting Result:

This is the log file which shows that the snort detects the above fake ARP packet

This packet captured by host C which shows the following:

CHAPTER 4

CONCLUSION AND RECOMMENDATIONS

In this study, we conducted an extensive experimental work to know which security solutions are able to detect a very dangerous MAC layer attack called “ARP Spoofing”. It is to be noted that ARP spoofing constitutes the beginning of many attacks, one of which is, the destructive MiM attack. We were able to show throw testing and experimentation that the current security solutions have many shortcomings and defects when it comes to detecting ARP Spoofing. On the other hand, XArp 2 tool was the most efficient available security solution that can cope with ARP spoofing attacks among the other solutions. However, it needs minor improvements, compared to the other security solutions, by adding mechanisms to detect an ARP request storm and ARP scanning. As a conclusion of our study, we suggested six basic and crucial requirements that any algorithm should follow in order to detect any type of ARP spoofing sufficiently on a switched Local Area Network [LAN]. A simple model was also made up to simulate a typical attack using the so far known types of ARP Spoofed Packets. An algorithm was implemented using C++ in a Workstation to simulate a network switch or a Firewall in order to detecting any type of ARP Spoofed packets in the lab.

Furthermore, the experiment showed that the algorithm was successful in filtering all 10 known types of ARP Spoofing attacks, on the other hand; the network performance was not considerably affected after applying the algorithm. This is due to the fact that ARP packets have no data encapsulated in its packet and are too small in size compared to TCP/IP packets in the normal data traffic.

We also recommend carrying on further study on this research area that may include but are not limited to the following:

• Testing the algorithm in Wide Area Network with thousand numbers of hosts connected to a network backbone and high volume of ARP spoofed attacks over the switch or firewall where the proposed algorithm is running.

• Calculating the performance of the network while the algorithm is up-and-running, and cross checking the result with our observations in the LAB and analyzing the algorithm performance on difference set up and configurations

• It is also recommended for all security solution providers to upgrade or update their devices Operating Systems [OS] to integrate the algorithm we proposed in our study, in order to ensure that all known types of ARP Spoofing attacks are addressed and detected by the security solution

Research Publishing

• This work was presented in:

- “The 2009 International Conference on the Current Trends in Information Technology [CTIT'09], on 16-Dec, 2009, www.ctit.ae/

- The paper entitled: “Towards more sophisticated ARP Spoofing Detection & Prevention systems in LAN network”

• Also published on IEEE Xplore IEEE

- Catalog Number: CFP0904J-PRT

- ISBN: 978-1-4244-5755-7

• Advanced research will continue:

- An abstract is being submitted and updated paper is accepted to be presenting in:

“The 11th ARC at UAE-University on April, 2010” and will be published in the conference proceeding, http://sra.uaeu.ac.ae/Conference_11/index.htm

APPENDIXES

Appendix [1]: The Internet Protocol Suite; based on layers (RFC 1122)

The Internet Protocol Suite (TCP/IP protocols)

Application Layer list:

BGP - DHCP - DNS - FTP - GTP - HTTP - IMAP - IRC - Megaco - MGCP - NNTP - NTP - POP - RIP - RPC - RTP - RTSP - SDP - SIP - SMTP - SNMP - SOAP - SSH - Telnet - TLS/SSL - XMPP…etc.

Transport Layer list:

TCP - UDP - DCCP - SCTP - RSVP - ECN…etc.

Internet Layer list:

IP (IPv4, IPv6) - ICMP - ICMPv6 - IGMP - IPsec…etc.

Link Layer list:

ARP - RARP - NDP - OSPF - Tunnels (L2TP) - PPP - Media Access Control (Ethernet, MPLS, DSL, ISDN, FDDI) - Device Drivers…etc.

Appendix [2]: The help menu for FrameIP Tool

FrameIP - Create some IP frame - Version 5.10.3.13

Create on December 21, 2002, Last compilation on June 02, 2009

Created by Sebastien FONTAINE - http://www.frameip.com

GENERAL OPTIONS

-? This help

-wait Wait after frame Default: 1000 ms

-loops Number of loops Default: 1 (0=>no stop)

-send_mode 0=Soket 1=Libpcap Default: 1

-view Show the answers Default: 1

FREE INTERFACES

0 - Generic dialup adapter

1 - Intel(R) PRO/Wireless 3945BG Network Connection (Microsoft's Packet Scheduler)

2 - Broadcom 440x 10/100 Integrated Controller (Microsoft's Packet Scheduler)

3 - Bluetooth PAN Driver (Microsoft's Packet Scheduler)

-interface Interface choice Default: 0

ETHERNET HEADER OPTIONS (-send_mode 1)

-mac_source @ Ethernet Default: a (r=>random a=>automatic)

-mac_destination @ Ethernet Default: FF-FF-FF-FF-FF-FF (r=>random a=>automatic)

-mac_type Between 0 & 65535 Default: 2048

ARP HEADER OPTIONS (-mac_type 2054)

-arp_type_hardware Header format Default: 256

-arp_type_protocol Protocol type Default: 8

-arp_length_hardware Header format Default: 6

-arp_length_protocol Protocol type Default: 4

-arp_opcode Operation type Default: 256 (1=>Request)

-arp_mac_source @ Mac source Default: 00-00-00-00-00-00

-arp_mac_source_auto Between 0 or 1 Default: 1 (1=>MAC from interface)

-arp_ip_source @ Ip source Default: 10.33.33.24 (r=>random)

-arp_mac_destination @ Mac destination Default: 00-00-00-00-00-00

-arp_ip_destination @ Ip destination Default: 192.168.101.254 (r=>random)

IP HEADER OPTIONS (-mac_type 2048)

-ip_version Between 0 & 15 Default: 4

-ip_ihl Between 0 & 15 Default: 5

-ip_tos Between 0 & 255 Default: 0

-ip_length Between 0 & 65535 Default: a (a=>automatic)

-ip_id Between 0 & 65535 Default: r (r=>random)

-ip_flag_zero Between 0 or 1 Default: 0

-ip_flag_mf Between 0 or 1 Default: 0

-ip_flag_df Between 0 or 1 Default: 0

-ip_offset Between 0 & 8191 Default: 0

-ip_ttl Between 0 & 255 Default: 128

-ip_type Between 0 & 255 Default: 1 (r=>random)

-ip_checksum Between 0 & 65535 Default: a (a=>automatic)

-ip_source @ Ip or host name Default: 10.33.33.24 (r=>random)

-ip_destination @ Ip or host name Default: 192.168.101.254 (r=>random)

ICMP HEADER OPTIONS (-ip_type 1)

-icmp_type Between 0 & 255 Default: 8

-icmp_code Between 0 & 255 Default: 0

-icmp_checksum Between 0 & 65535 Default: a (a=>automatic)

-icmp_id Between 0 & 65535 Default: r (r=>random)

-icmp_sequence Between 0 & 65535 Default: r (r=>random)

IGMP HEADER OPTIONS (-ip_type 2)

-igmp_version Between 0 & 15 Default: 1

-igmp_type Between 0 & 15 Default: 1

-igmp_reserve Between 0 & 255 Default: 0

-igmp_checksum Between 0 & 65535 Default: a (a=>automatic)

-igmp_destination @ Ip or host name Default: 224.0.0.1 (r=>random)

TCP HEADER OPTIONS (-ip_type 6)

-tcp_port_source Between 0 & 65535 Default: r (r=>random)

-tcp_port_destination Between 0 & 65535 Default: 80 (r=>random)

-tcp_sequence Between 0 & 2E16 Default: r (r=>random)

-tcp_acknowledge Between 0 & 2E16 Default: 0

-tcp_offset Between 0 & 15 Default: 5

-tcp_reserved Between 0 & 63 Default: 0

-tcp_flag_urg Between 0 or 1 Default: 0

-tcp_flag_ack Between 0 or 1 Default: 0

-tcp_flag_psh Between 0 or 1 Default: 0

-tcp_flag_rst Between 0 or 1 Default: 0

-tcp_flag_syn Between 0 or 1 Default: 1

-tcp_flag_fin Between 0 or 1 Default: 0

-tcp_window Between 0 & 65535 Default: 0

-tcp_checksum Between 0 & 65535 Default: a (a=>automatic)

-tcp_pointeur Between 0 & 65535 Default: 0

UDP HEADER OPTIONS (-ip_type 17)

-udp_port_source Between 0 & 65535 Default: r (r=>random)

-udp_port_destination Between 0 & 65535 Default: 53 (r=>random)

-udp_length Between 0 & 65535 Default: a (a=>automatic)

-udp_checksum Between 0 & 65535 Default: a (a=>automatic)

RIP HEADER OPTIONS (-udp_port_destination 520)

-rip_status 1:request 2:answer Default: 2

-rip_version Between 0 & 255 Default: 2

-rip_domain Between 0 & 65535 Default: 0

-rip_protocol Between 0 & 65535 Default: 2

-rip_tag Between 0 & 65535 Default: 0

-rip_route @ Ip Default: 192.168.0.0 (r=>random)

-rip_mask Mask Default: 0.0.0.0 (r=>random)

-rip_gateway Netx Hop Default: 0.0.0.0 (r=>random)

-rip_metric Between 0 & 65535 Default: 1

-rip_file_name List of routes Default:

OPTIONS OF THE DATA LAYER

-data_size data size Default: 15

-data_ascii specify a string Default: www.frameip.com

-data_hexa specify some hexa Default: 7777772e6672616d6569702e636f6d

References

[1] CERT: http://www.cert.org

[2] Wikipedia: http://en.wikipedia.org/wiki/Man_in_the_middle_attack

[3] WebOpedia:http://www.webopedia.com/TERM/s/sniffer.html

[4] Plummer D. An Ethernet address resolution protocol, RFC 826, MIT-LCS, November1982.

[5] Trabelsi Z., 2009. Introduction: TCP/IP Protocol & IP Address. PowerPoint lecture presented in CIT College on UAE University campus

[6] Cisco Systems, 2009. Internetworking Technologies Handbook, Fiber Distributed Data Interface, Chapter 8, pp 125-136.

[7] Wendell Odam, 2000. Cisco CCNA Certification Guide. Cisco Systems, Chapter 5, pp 225-228.

[8] Trabelsi Z., 2009. ARP-RARP Protocols. PowerPoint lecture presented in CIT College on UAE University campus.

[9] Whalen S., 2009. An Introduction to ARP Spoofing, http://www.node99.org/papers/arpspoof.pdf

[10] Wikipedia, Address Resolution Protocol, (as of July 17, 2009, 12:47 GMT). http://en.wikipedia.org/wiki/Address_Resolution_Protocol

[11] Abad C., and Bonilla R., 2007. An Analysis on the Schemes for Detecting and Preventing; ARP Cache Poisoning Attacks, Proceedings of 27th International Conference on Distributed Computing Systems Workshops (ICDCSW'07), Toronto, Ontario, Canada. IEEE Computer Society 2007, pp 25-29.

[12] Houghton M. H., 2009. The American Heritage Dictionary of the English Language, 4th Edition.

[13] The 6th Annual Global Security Survey, 2009. Deloitte Touche Tohmatsu, London. http://www.deloitte.com/dtt/cda/doc/content/dtt_fsi_GlobalSecuritySurvey_0901.pdf

[14] Symbiotic Media Consortium: http://www.symbiotic.co.ke/2009/08/it-security-is-your-data-safe-from-both-external-and-internal-attack/

[15] Wasiq M., ARP Cache Poisoning Man-In-The-Middle-Attack, (as of August 16, 2009, 06:45 GMT).

http://www.ccse.kfupm.edu.sa/pages/services/pc_security/ARPCachePoisoning.doc

[16] Trabelsi Z., and Shuaib K., 2008. A Novel Man-in-the-Middle Intrusion Detection Scheme for Switched LANs, The International Journal of Computers and Applications, ACTA Press, USA, Vol.30, 202-2195.

[17] Trabelsi Z., 2009. ARP Cache Poisoning based Attacks. PowerPoint lecture presented in CIT College on UAE University campus

[18] Wikipedia, Man-in-the-Middle attack, (as of July 17, 2009, 12:47 GMT) http://en.wikipedia.org/wiki/Man-in-the-middle_attack

[19] Roy D., Moazzami K., and Singh R., 2007. ARP Spoofing and Man in the Middle attack using Ettercap, School of Computer Science, University of Windsor, Canada.

[20] Koc C., Yerubandi S., and Wanalertlak W., 2002 SSH1 MAN IN THE MIDDLE ATTACK: Computer Network Security, Oregon State University, USA.

[21] Nelson T., 2005. Control Systems Security Center, Common Control System Vulnerability, Idaho National Laboratory.

[22] Trabelsi Z., and Shuaib K., 2008. Spoofed ARP Packets Detection in Switched LAN Networks. In Joaquim,F., Mohammad,O. (Eds.), E-Business and Telecommunication Networks. Portugal: Springer Berlin Heidelberg, pp. 81-91.

[23] LBNL's Network Research Group, Arpwatch: Ethernet Monitor Program, http://www-nrg.ee.lbl.gov

[24] Snort: http://www.snort.org/

[25] Jonathan Wilkins: http://www.bitland.net/taranis

[26] (IDS) inspects all inbound and outbound network activity and identifies suspicious attack.

[27] (IPS) provides policies and rules for network traffic along with IDS for alerting system Admin to a suspicious traffic.

[28] Bruschi D., Ornaghi A., andRosti E.2003. S-ARP: a secure address resolution protocol, Proceedings of the 19th Annual Computer Security Applications Conference (ACSAC 2003), Las Vegas, NV, USA, pp 66 - 74, 8-12.

[29] Omkant P., 2002 “O-ARP: a secure and fast Address Resolution Protocol”, http://www.itbhu.ac.in/departments/comp/crypto/o-arp.pdf

[30] Gouda M., and Huang CT., 2003. A Secure Address Resolution Protocol, The International Journal of Computer and Telecommunications Networking, Computer Networks, Elsevier, Volume 41, Issue 1, pp 57-71.

[31] Lootah W., Enck W., and McDaniel P., 2005. TARP: Ticket-based Address Resolution Protocol, 21st Annual Computer Security Applications Conference (ACSAC 2005), Tucson, Arizona, USA.

[32] Vipul G.,Rohit T.,Colin B., and GonzálezJuan M., 2005. An efficient solution to the ARP cache poisoning problem, Lecture Notes in Computer Science, Australasian conference on information security and privacy (ACISP), Brisbane, AUSTRALIA, No.10, vol.3574,pp.40-51.

[33] Etienne J., 2000. ARPSec, an ARP security extension, Linux Symposium, July 19-22nd, Ottawa, Canada

[34] Kent S., and Atkinson R., 1998. Security Architecture for the Internet Protocol, RFC 2401.

[35] Oppliger R., Hausser R., and Basin D., 2006. SSL/TLS session-aware user authentication - Or how to effectively thwart the man-in-the-middle, Computer Communications, Elsevier, Article in Press.

[36] Rivest L., and Shamir A., 1984. How to expose an Eavesdropper, Communications of the ACM 27 (4), pp 393-395.

[37] Bellovin M., and Merritt M., 1994. An attack on the interlock protocol when used for authentication, IEEE Transactions on Information Theory 40 (1).

[38] Jakobsson M., and Myers S., 2005. Stealth attacks and delayed password disclosure. http://www.informatics.indiana.edu/markus/stealth-attacks.htm/

[39] Kaliski B., and Nystrom M., 2004. Authentication: risk vs. readiness, challenges and solutions, in: Presentation held at the BITS Protecting the Core Forum. http://www.rsa.com/rsalabs/staff/bios/bkaliski/publications/other/kaliski-authentication-risk-readiness-bits-2004.ppt

[40] Asokan N., Niemi V., Nyberg K., 2003. Man-in-the-middle in tunneled authentication protocols, in: Proceedings of the International Workshop on Security Protocols, pp 15-24.

[41] Anatomy of an ARP poisoning attack. http://www.watchguard.com/infocenter/editorial/135324.asp.

[42] Cisco Systems. Catalyst 4500 Series Switch Cisco IOS Software Configuration Guide, http://www.cisco.com

[43] Al-Hemairy M., Trabelsi Z., and Amin S., 2009. Towards more Sophisticated ARP Spoofing Detection/Prevention Systems in LAN Networks, Proceedings of “The 2009 International Conference on the Current Trends in Information Technology (CTIT'09)”, HCT Dubai, UAE. IEEE Xplore Catalog Number: CFP0904J-PRT. ISBN: 978-1-4244-5755-7

[44] Cisco Catalyst 3560 Series Switches, http://www.cisco.com

[45] Juniper Switches EX3200 Series, http://www.juniper.net

[46] Abad C., and Bonilla R., 2007. An Analysis on the Schemes for Detecting and Preventing ARP Cache Poisoning Attacks, Proceedings of the 27th International Conference on Distributed Computing Systems Workshops (ICDCSW'07).

[47] FrameIP: www.FrameIP.com

[48] WinPcap: www.WinPcap.org

[49] Commview: http://www.tamos.com/products/commview/

[50] Brown M., 2007. Guide to IP Layer Network Administration with Linux: Address Resolution Protocol (ARP), chapter 2. http://linux-ip.net/html/ether-arp.html

[51] Baccala B., 1997. Connected: An Internet Encyclopedia: ARP Protocol Overview. http://www.freesoft.org/CIE/Topics/61.htm