22-06-2012, 02:40 PM
IDS for detecting ARP cache poisoning attack using Java
Objective
Monitoring packets to detect ARP cache poisoning attack performed in the LAN. In this
project we developed an Intrusion detection system to find ARP poisoning attack. The IDS sniffs all
the data packets flowing in the network and checks only the ARP packet to detect whether any
spoofed ARP packet is flowing in the network.
Background Environment Requirements
Operating system: Windows(XP, Vista or Windows-7) or any Linux where libpcap package can be
installed. Administration privilege in Windows and root access in Linux.
Software requirements:
i. WinPcap – for Windows operating system
ii. libpcap package – for Linux operating system
iii. sun-java6-jdk or higher version
iv. netbeans IDE (optional. But used at the time of development)
v. Jpcap – a Java package used for capturing network packets
Hardware requirements:
i. Computers with networking capability
ii. Managed switch, having a monitoring port
iii. And cables
Summary of the project
problem faced:
So ARP is used for mapping from IP to MAC. All the IP packets in the network will be
destined to a particular IP address. That IP address is sufficient only upto the network layer of the
OSI model. After that it needs the MAC address of the destination device. Here comes ARP. The
data link layer generates a ARP request for the IP to which it needs MAC and broadcasts the request
to all the systems in the network. The system that have the requested IP will reply the system with
its MAC address.
All the systems in the network maintaining a cache that stores the IP and the corresponding
MAC. The cache is a temporary storage. An entry in the cache is maintained only for a particular
time (around 20 minutes). When a system receives an ARP request, it updates its cache with the
source IP and the source MAC of the received ARP request. Also the cache will be updated with the
destination IP and MAC while it receives an ARP reply. This cache is used for future reference. If
an entry for a particular IP is present in the cache, the system won't generate an ARP request.
Instead it will simply send the packet to the MAC for that IP present in the cache.
The problem with ARP is, ARP is a stateless protocol. It means, a system will forget about it
after sending an ARP request. So it will not bother about how many replies have been received. It
will just update its cache as long as it receives ARP reply. Also the system won't check its cache
before updating it. Even though there was an another entry for the same MAC received in the ARP
reply, the system will made a new entry in its cache with the new IP and the MAC. It made the
attacker very easy to spoof the network.
Proposed solution:
This solution is made for only static IP networks. Here in this method, we have developed an
IDS (Intrusion Detection System). That will monitor the network and report the administrator if any
attack performed in ARP. In this method, a system is dedicated for monitoring, where the IDS is
present. And the switch will be configured to forward a copy of all the packets passing through it to
the monitoring system. And all the nodes in the network are connected through the switch.
The IDS will filter only the ARP packets and discard all the other packets. Also the IDS
maintains a list database which contains all the legitimate IP MAC combinations. That database
should be entered by the network administrator manually.
After receiving an ARP packet, the IDS checks whether the received packet is ARP request
or reply. If it is an ARP request, the IDS extracts the source IP and MAC from the ARP packet and
compares it with the entries in the database. Or if the packet is ARP reply, it checks both source and
destination IP MAC combinations with the database. So if the combinations are not present in the
database, the IDS will alert the administrator.
Design specification:
First the switch is configured for monitoring. So one of its port will be assigned for
monitoring. And the IDS system is connected to the switch through the monitoring port. Thus a
copy of all the packets passing through the switch will be sent to the monitoring system.
In the monitoring system NetworkSniffer, a Java object is running. That object captures all
the packets coming through the monitoring port. It checks for ARP packet. If any of ARP request or
reply received, it creates a new object of ARPCheck and passes the ARP packet to that object. If the
received packet is not an ARP packet, NetworkSniffer just ignores the packet.
After receiving the ARP packet, the ARPCheck object extracts source IP, MAC, destination
IP, MAC and the type of the packet (request or reply). If the received ARP packet is an ARP request,
it checks the source IP, MAC combination with the entries in the database consisting legitimate IP,
MAC combinations, which are entered by the network administrator manually. Or if the ARP packet
is ARP reply, it checks both source IP, MAC and destination IP, MAC combinations with the
database.
In the above testing by ARPCheck object, if any ARP packet is found as having IP, MAC
combination that is not present in the database, then it will alert the administrator with the
information received from the ARP packet. Or the packet having only legitimate IP, MAC
combinations, it just enters into the log.
Also another module is created. That is Java object and its name is Entry. It is used to make
entry in the database and delete entries from the database.
Future Scope
This project can be extended to dynamic networks also. This can be done by extending the
NetworkSniffer to read DHCP packet. Using this the entry in the database can be automatically
entered from the information in the DHCP packet. Also ARP cache poisoning attack can be
prevented by configuring the switch to control the flow of ARP packets in the network.