Arp-scan User Guide
Contents
- 1 Introduction to arp-scan
- 2 Introduction to the ARP protocol
- 3 Using arp-scan for system discovery
- 4 Using arp-scan for system fingerprinting
- 5 802.2 LLC/SNAP Framing
- 6 Other Techniques
- 6.1 Identifying secondary IP addresses
- 6.2 Identifying interfaces on the same system
- 6.3 Identifying Proxy ARP
- 6.4 Load balancing protocol MAC Addresses
- 6.5 Linux IP Routing
- 6.6 802.11 wireless networks
- 6.7 Determining the interface netmask
- 6.8 Discovering other interface addresses
- 6.9 Setting ar$spa to the destination address
- 6.10 Debugging with --verbose
- 6.11 802.1Q VLAN Hopping
- 6.12 Writing responses to a PCAP Savefile
- 7 Unusual Behaviour
- 8 Keeping the vendor data up to date
Introduction to arp-scan
arp-scan is a command-line tool for system discovery and fingerprinting. It constructs and sends ARP requests to the specified IP addresses, and displays any responses that are received.
arp-scan allows you to:
- Send ARP packets to any number of destination hosts, using a configurable output bandwidth or packet rate.
- This is useful for system discovery, where you may need to scan large address spaces.
- Construct the outgoing ARP packet in a flexible way.
- arp-scan gives control of all of the fields in the ARP packet and the fields in the Ethernet frame header.
- Decode and display any returned packets.
- arp-scan will decode and display any received ARP packets and lookup the vendor using the MAC address.
- Fingerprint IP hosts using the arp-fingerprint tool.
Introduction to the ARP protocol
ARP (Address Resolution Protocol) is a protocol that determines the link-layer (layer-2) address for a given network layer (layer-3) address. ARP is defined in RFC 826 An Ethernet Address Resolution Protocol.
The ARP protocol is designed to allow it to be used for any link-layer and network-layer protocols. However in practice it is only used for Ethernet (including 802.11 wireless) and IPv4, and we assume these protocols throughout this document. IPv6 uses NDP (neighbour discovery protocol) instead, which is a different protocol.
ARP is a non-routable protocol, and can therefore only be used between systems on the same Ethernet network.
ARP Packet Diagram
The diagram below shows an example ARP packet within an Ethernet frame:
The Ethernet frame contains the MAC header followed by the ARP packet data. Both the MAC header and ARP packet data consist of a number of fields, each of which contains sample data in hexadecimal and a field name. The field names in the ARP packet data are from RFC 826. The numbers in multi-byte fields are in network byte order, or big endian, with the high value byte first.
In the diagram, the packet is an ARP request (ar$op = 0001) for the IP address 10.0.0.2 (ar$tpa). It was sent from the system with MAC address 00:C0:9F:09:B8:DB (both MAC source address and ar$sha) and IP address 10.0.0.1 (ar$spa). The packet is sent to the all stations broadcast address FF:FF:FF:FF:FF:FF (MAC destination address).
This packet is displayed by tcpdump as follows:
00:c0:9f:09:b8:db > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 10.0.0.2 tell 10.0.0.1
And a raw hex dump of the packet, including the Ethernet MAC header is:
ff ff ff ff ff ff 00 c0 9f 09 b8 db 08 06 00 01 08 00 06 04 00 01 00 c0 9f 09 b8 db 0a 00 00 01 00 00 00 00 00 00 0a 00 00 02
The two tables below describe the fields in the Ethernet MAC header and the ARP protocol data.
MAC Header Fields
| Field Name | Size (Bits) | Function | Notes |
|---|---|---|---|
| Dest Address | 48 | Frame destination address | By default ARP requests are sent to the broadcast address ff:ff:ff:ff:ff:ff |
| Source Address | 48 | Frame source address | Default is the address of the outgoing interface |
| Protocol Type | 16 | Ethernet protocol type | The ARP protocol type is 0806 |
The length of the MAC header is 14 bytes (112 bits).
ARP Protocol Data Fields
| Field Name | Size (Bits) | Function | Notes |
|---|---|---|---|
| ar$hrd | 16 | ARP Hardware Type | Default is 0001 (Ethernet) |
| ar$pro | 16 | ARP Protocol Type | Default is 0800 (IPv4) |
| ar$hln | 8 | Link Layer Hardware Address Length | Default is 6 bytes (48 bits) |
| ar$pln | 8 | Network Protocol Address Length | Default is 4 bytes (32 bits) |
| ar$op | 16 | ARP Opcode | 0001 for ARP Request or 0002 for ARP Reply |
| ar$sha | 48 | Sender Hardware Address | Default is the address of the outgoing interface |
| ar$spa | 32 | Sender Network Protocol Address | Default is the IP address of the outgoing interface |
| ar$tha | 48 | Target Hardware Address | Default is zero for ARP requests |
| ar$tpa | 32 | Target Network Protocol Address | For ARP requests, this is the IP address that we wish to find |
The length of the ARP protocol data is 28 bytes (224 bits). This is less than the minimum Ethernet data length of 46 bytes, so the ARP data will always be followed by at least 18 bytes of padding.
Using arp-scan for system discovery
arp-scan can be used to discover IP hosts on the local network. It can discover all hosts, including those that block all IP traffic such as firewalls and systems with ingress filters.
arp-scan works on Ethernet and 802.11 wireless networks. It may also work with token ring and FDDI, but they have not been tested. It does not support serial links such as PPP or SLIP, because ARP is not supported on them.
You will need to be root, or arp-scan must be SUID root, in order to run arp-scan, because the functions that it uses to read and write Ethernet packets require root privilege.
Discovering all hosts on the local network
If the system you are testing from has an address on the network you wish to scan, the simplest way to scan it is with a command similar to:
arp-scan --interface=eth0 --localnet
Here, --interface=eth0 represents the interface to use for scanning, and --localnet makes arp-scan scan all possible IP addresses on the network connected to this interface, as defined by the interface IP address and netmask. You can omit the --interface option, in which case arp-scan will search the system interface list for the lowest numbered, configured up interface (excluding loopback).
The network interface name depends on the operating system you are using, the network type (Ethernet, Wireless Etc), and for some operating systems on the interface card type as well. In this document, the interface name eth0 is used for examples except where a different network type is being discussed.
All arp-scan options have both a long form like --interface=eth0 and a corresponding short form like -I eth0. I always use the long form in this document for clarity.
Here is an example showing arp-scan being run against the local network:
$ arp-scan --interface=eth0 --localnet Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.5.2 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.1.1 00:c0:9f:09:b8:db QUANTA COMPUTER, INC. 192.168.1.4 00:02:b3:bb:5c:09 Intel Corporation 192.168.1.3 00:02:b3:bb:66:98 Intel Corporation 192.168.1.5 00:02:a5:90:c3:e6 Compaq Computer Corporation 192.168.1.6 00:c0:9f:0b:91:d1 QUANTA COMPUTER, INC. 192.168.1.8 00:02:b3:3d:13:5e Intel Corporation 192.168.1.9 00:02:b3:bb:66:bd Intel Corporation 192.168.1.10 00:02:b3:63:cd:16 Intel Corporation 192.168.1.12 00:02:a5:de:c2:17 Compaq Computer Corporation 192.168.1.13 00:02:b3:91:4e:74 Intel Corporation 192.168.1.14 00:02:a5:a9:27:29 Compaq Computer Corporation 192.168.1.17 00:12:3f:ae:c1:df Dell Inc 192.168.1.19 00:90:27:43:c0:57 INTEL CORPORATION 192.168.1.24 00:12:3f:d4:3c:06 Dell Inc 192.168.1.29 00:08:74:c0:89:1d Dell Computer Corp. 192.168.1.34 00:08:74:c0:40:ce Dell Computer Corp. 192.168.1.36 00:0c:29:d0:a2:18 VMware, Inc. 192.168.1.44 00:18:8b:7a:fe:10 Dell 192.168.1.47 00:12:3f:d4:41:86 Dell Inc 192.168.1.105 00:13:72:09:ad:76 Dell Inc. 192.168.1.148 00:90:27:9d:2a:0b INTEL CORPORATION 192.168.1.155 00:10:db:74:d0:52 Juniper Networks, Inc. 192.168.1.189 00:14:38:93:93:7e Hewlett Packard 192.168.1.191 00:01:e6:57:8b:68 Hewlett-Packard Company 192.168.1.195 00:10:83:f2:83:76 HEWLETT-PACKARD COMPANY 192.168.1.196 00:30:c1:ae:31:5c HEWLETT-PACKARD 192.168.1.204 00:11:43:0f:f2:dd DELL INC. 192.168.1.202 00:d0:b7:25:61:6c INTEL CORPORATION 192.168.1.222 00:90:27:9d:48:90 INTEL CORPORATION 192.168.1.192 00:01:e6:27:27:6e Hewlett-Packard Company 192.168.1.234 00:c0:9f:0d:00:9a QUANTA COMPUTER, INC. 192.168.1.251 00:04:27:6a:5d:a1 Cisco Systems, Inc. 192.168.1.250 00:06:d7:55:0f:40 Cisco Systems, Inc. 34 packets received by filter, 0 packets dropped by kernel Ending arp-scan 1.5.2: 256 hosts scanned in 1.717 seconds (149.10 hosts/sec). 33 responded
Here arp-scan scans the 192.168.1.0/24 network attached to eth0. It sends an ARP request for each IP address in the attached network (including the network and broadcast addresses) and for each host that responds, it displays the host's IP address, MAC address and the vendor string corresponding to the MAC address (this is generally determined by the first three bytes of the MAC address).
Any hosts that respond to the ARP request are displayed in the format:
<IP Address> <Hardware Address> <Vendor Details>
The IP address, Hardware address and vendor details are each separated by a single TAB character. There is always a single blank line between the last responding system and the statistics display.
arp-scan will never report the scanning host's own IP address, because the testing system won't respond to its own ARP request. This is generally the desired behaviour, as we are almost never interested in the details of the testing system.
Although arp-scan reports the datalink type as EN10MB, this does not necessarily mean that it is 10Mbit Ethernet; it could by any type (10Mbit, 100Mbit, 1Gbit or 802.11a/b/g). EN10MB is the name used by libpcap for all types of Ethernet.
Specifying a list of IP addresses
It is possible to specify a list of IP addresses to send ARP requests for instead of using --localnet to specify all the addresses within the attached network. There are five ways to specify the list of target addresses:
- Specify a list of IP addresses as arguments, e.g. arp-scan --interface=eth0 192.168.1.1 192.168.1.2 192.168.1.3
- Specify the network in <network>/<bits> format, e.g. arp-scan --interface=eth0 192.168.1.0/24
- Specify the network in <network>:<netmask> format, e.g. arp-scan --interface=eth0 192.168.1.0:255.255.255.0
- Specify the inclusive address range in <start>-<end> format, e.g. arp-scan --interface=eth0 192.168.1.3-192.168.1.27
- Read the list of IP addresses from a file, e.g. arp-scan --interface=eth0 --file=ip-address-list.txt
For the network specifications, <network>/<bits> and <network>:<netmask>, the resulting list of IP addresses includes the network and broadcast addresses. When reading the IP addresses from a file, the file should contain one IP address per line.
It is possible to use hostnames instead of IP addresses, e.g. arp-scan --interface=eth0 orion. This will lookup the IP address for orion with gethostbyname(). It is possible to disable this, so that all arguments must be IP addresses, with the --numeric option. In this case, the inet_pton() function is used to convert the IP address string.
The --numeric option is useful when DNS is not working, where it can avoid long delays caused by failed DNS lookups. If you find that arp-scan is taking a long time to run, this is one of the first things to try.
Don't forget that the ARP protocol only works on the local Ethernet segment, and cannot be routed. So you cannot use arp-scan to discover hosts behind routers with the exception of remote interfaces on some multi-homed systems, and proxy-arp responses from routers.
Here is an example showing arp-scan being run against the eight addresses in the network 192.168.1.0/29:
$ arp-scan --interface=eth0 192.168.1.0/29 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.5.2 with 8 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.1.1 00:c0:9f:09:b8:db QUANTA COMPUTER, INC. 192.168.1.3 00:02:b3:bb:66:98 Intel Corporation 192.168.1.4 00:02:b3:bb:5c:09 Intel Corporation 192.168.1.5 00:02:a5:90:c3:e6 Compaq Computer Corporation 192.168.1.6 00:c0:9f:0b:91:d1 QUANTA COMPUTER, INC. 6 packets received by filter, 0 packets dropped by kernel Ending arp-scan 1.5.2: 8 hosts scanned in 0.885 seconds (9.04 hosts/sec). 5 responded
Using an interface without an IP address
You can still use arp-scan even if the interface does not have an IP address. If you use arp-scan in this way, it will use the IP address of 0.0.0.0 for the ar$sha field in the ARP packet unless you specify the IP address to use with the -arpsha option.
Some operating systems will only respond to ARP requests if the IP address specified in the ar$sha field is plausible. The exact rules vary between operating systems, but the most common is that the address in ar$sha must be within the IP network of the interface that the ARP request is received on. This is explored further in the fingerprinting section.
Memory Usage
The list of target hosts is stored in memory. Each host in this list uses 28 bytes of memory, so scanning a Class-B network (65,536 hosts) requires about 1.75MB of memory for the list, and scanning a Class-A (16,777,216 hosts) requires about 448MB.
Each host entry is described by the following C structure:
typedef struct {
unsigned timeout; /* Timeout for this host in us */
struct in_addr addr; /* Host IP address */
struct timeval last_send_time; /* Time when last packet sent to this addr */
unsigned short num_sent; /* Number of packets sent */
unsigned short num_recv; /* Number of packets received */
unsigned char live; /* Set when awaiting response */
} host_entry;
Timing and bandwidth usage
One ARP packet is sent for each for each target host, with the target protocol address (the ar$tpa field) set to the IP address of this host. If a host does not respond, then the ARP packet will be re-sent once more. The maximum number of retries can be changed with the --retry option. Reducing the number of retries will reduce the scanning time at the possible risk of missing some results due to packet loss.
You can specify the bandwidth that arp-scan will use for the outgoing ARP packets with the --bandwidth option. By default, it uses a bandwidth of 256000 bits per second. Increasing the bandwidth will reduce the scanning time, but setting the bandwidth too high may result in an ARP storm which can disrupt network operation. Also, setting the bandwidth too high can send packets faster than the network interface can transmit them, which will eventually fill the kernel's transmit buffer resulting in the error message: No buffer space available. Another way to specify the outgoing ARP packet rate is with the --interval option, which is an alternative way to modify the same underlying parameter.
The time in seconds to perform a single-pass scan (i.e. with --retry=1) is given by:
time = n*i + t + o
Where n is the number of hosts in the list, i is the time interval between packets (specified with --interval, or calculated from --bandwidth), t is the timeout value (specified with --timeout) and o is the overhead time taken to load the targets into the list and read the MAC/Vendor mapping files. For small lists of hosts, the timeout value will dominate, but for large lists the packet interval is the most important value.
With 65,536 hosts, the default bandwidth of 256,000 bits/second (which results in a packet interval of 2ms), the default timeout of 100ms, and a single pass (--retry=1), and assuming an overhead of 1 second, the scan would take 65536*0.002 + 0.1 + 1 = 132.172 seconds, or about 2 minutes 12 seconds.
Using arp-scan for system fingerprinting
In addition to system discovery, you can also use arp-scan to perform various types of system fingerprinting as detailed below. This is particually useful on Firewalls and systems employing IP ingress filtering that do not have any accessible IP network services.
MAC Vendor Decoding
Unless the --quiet option is specified, arp-scan decodes the vendor details from the MAC address and displays these details in the third column, after the MAC address. Below is an example using a Cisco router where the vendor details are Cisco Systems, Inc.
192.168.1.251 00:04:27:6a:5d:a1 Cisco Systems, Inc.
arp-scan uses data from three files to decode the vendor details:
- ieee-oui.txt - This the IEEE OUI (Organizationally Unique Identifier) list, which is obtained from the IEEE website and can be updated with the get-oui script that is included with arp-scan.
- ieee-iab.txt - This the IEEE IAB (Individual Address Block) list, which is obtained from the IEEE website and can be updated with the get-iab script that is included with arp-scan.
- mac-vendor.txt - This is a list of other MAC address / vendor mappings. This list is manually maintained, and is much smaller than the OUI and IAB listings.
When arp-scan starts up it reads the contents of all three files into a hash table, and it matches the MAC addresses of any ARP replies that it receives against this hash table to decode the vendor string.
The vendor details can often help to identify the device type. In the example above, the vendor string Cisco Systems, Inc. suggests that the device is a Cisco.
The vendor details depend on the manufacturer of the network interface, which may well be different from the manufacturer of the entire system, e.g. a 3COM Ethernet card in an HP server.
Differences in responses to non-standard ARP packets
Different IP stack implementations respond differently to non-standard ARP packets. arp-scan includes the arp-fingerprint tool that uses these differences to fingerprint the implementation. arp-fingerprint is a Perl script, which uses arp-scan to send and receive the ARP packets. The table below shows the tests that arp-fingerprint performs:
| No. | Description | arp-scan option | Notes |
|---|---|---|---|
| 1 | source protocol address = localhost | --arpspa=127.0.0.1 | IP address 127.0.0.1 should never appear as a source address on the LAN |
| 2 | source protocol address = zero | --arpspa=0.0.0.0 | |
| 3 | source protocol address = broadcast | --arpspa=255.255.255.255 | |
| 4 | source protocol address = non-local | --arpspa=1.0.0.1 | IP network 1.0.0.0/8 is reserved by IANA, so should never belong on the target's local LAN |
| 5 | Invalid Opcode | --arpop=255 | Opcode 255 is not defined |
| 6 | Hardware Type = IEEE_802.2 | --arphrd=6 | Most systems respond to this as well as the default hardware type 1 |
| 7 | Invalid hardware type | --arphrd=255 | |
| 8 | Invalid protocol type | --arppro=0xffff | |
| 9 | Protocol type = IPX | --arppro=0x8137 | |
| 10 | Invalid protocol address length | --arppln=6 | The protocol address length is normally four bytes |
| 11 | Invalid hardware address length | --arphln=8 | The hardware address length is normally six bytes |
Each of these tests results in a yes/no answer depending on whether the target host responded or not. arp-fingerprint constructs a string of binary digits from the responses to the tests, with a response being encoded as "1" and no response being "0", and uses the resultant binary string to match against a list of known fingerprints.
Below are some examples of arp-fingerprint being used against some different targets. arp-fingerprint displays the IP address, the binary fingerprint string, and a list of known systems that match this fingerprint:
$ arp-fingerprint -o "--interface=eth0 --numeric" 192.168.1.1 192.168.1.1 01000100000 Linux 2.2, 2.4, 2.6
$ arp-fingerprint -o "--interface=eth0 --numeric" 192.168.1.204 192.168.1.204 11110100000 FreeBSD 5.3, Win98, WinME, NT4, 2000, XP, 2003
$ arp-fingerprint -o "--interface=eth0 --numeric" 192.168.1.251 192.168.1.251 00000100000 Cisco IOS 11.2, 11.3, 12.0, 12.1, 12.2, 12.3, 12.4
$ arp-fingerprint -o "--interface=eth0 --numeric" 192.168.1.155 192.168.1.155 01000111111 ScreenOS 5.0, 5.1, 5.3, 5.4
In each of the examples above we use arp-fingerprint's -o option to pass the --interface=eth0 --numeric option string to arp-scan. The -o option can be used to pass any options to arp-scan, with the two most common ones being --interface to specify the network interface and --numeric to avoid DNS lookups.
Many of the fingerprint strings are shared by several operating systems, so there is not always a one-to-one mapping between fingerprint strings and operating systems. Also the fact that a system's fingerprint matches a certain operating system (or list of operating systems) does not necessarily mean that the system being fingerprinted is that operating system, although it is quite likely. This is because the list of operating systems is not exhaustive; it is just what I have discovered to date, and there are bound to be operating systems that are not listed.
Sometimes, an operating system can give different fingerprints depending on the configuration. An example is Linux, which will respond to a non-local source IP address if that IP is routed through the interface being tested. This is both good and bad: on one hand it makes the fingerprinting task more complex; but on the other, it can allow some aspects of the system configuration to be determined.
Sometimes the fact that two different operating systems share a common ARP fingerprint string points to a re-use of networking code. One example of this is Windows NT and FreeBSD.
If you find a system that arp-fingerprint reports as UNKNOWN, and you know what operating system it is running, please send details of the operating system and fingerprint to arp-scan@nta-monitor.com so I can include it in future versions. Please include the exact version of the operating system if you know it, as fingerprints sometimes change between versions.
Changing the destination MAC Address
arp-scan sends the ARP requests to the Ethernet broadcast address ff:ff:ff:ff:ff:ff by default, but this can be changed with the --destaddr option.
An interface that is not in promiscuous mode will pass Ethernet packets to the operating system if the destination address is one of:
- The Ethernet broadcast address ff:ff:ff:ff:ff:ff;
- The interface's unicast address; or
- An Ethernet multicast address that the system is listening on.
You can always use the target system's MAC address as the target if you know it. This can be useful to check that a given system with known IP and MAC addresses is present on the LAN, and it has the advantage that it is quieter than using the broadcast because it won't be received by all network stations.
Below is an example of using a host's unicast MAC address. In this example, we first use arp-scan with the default broadcast destination to determine the host's MAC address, and then run arp-scan again specifying the host's MAC address as the detination.
$ arp-scan --interface=eth0 192.168.1.1 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.5.2 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.1.1 00:c0:9f:09:b8:db QUANTA COMPUTER, INC.
$ arp-scan --interface=eth0 --destaddr=00:c0:9f:09:b8:db 192.168.1.1 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.5.2 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.1.1 00:c0:9f:09:b8:db QUANTA COMPUTER, INC.
If you send the ARP requests to an Ethernet multicast address it will only be received by those systems that are listening on that multicast address, or have set their Ethernet interface into promiscuous mode (and therefore receive all packets). This can be used to find systems that are running in promiscuous mode, or listen on particular multicast addresses.
The table below shows some common Ethernet multicast addresses:
| Multicast Address | Description |
|---|---|
| 01:00:0c:cc:cc:cc | CDP (Cisco Discovery Protocol) |
| 01:00:0c:cc:cc:cd | SSTP (Shared Spanning Tree Protocol) |
| 01:80:c2:00:00:00 | Spanning Tree |
| 01:00:5e:00:00:05 | OSPF |
| 01:00:5e:00:00:12 | VRRP |
| 03:00:c7:00:00:ee | HP network teaming |
Detecting Systems Listening to OSPF Multicasts
This example shows the use of the --destaddr option with the OSPF multicast address to detect systems listing to OSPF multicasts.
First we scan three systems using the default options. The IP addresses are 192.168.1.1, 192.168.1.204 and 192.168.1.254, which are running Linux 2.6.19, Windows 2003 and Cisco IOS 12.2(29) respectively. All three systems respond as expected.
$ arp-scan --interface=eth0 192.168.1.1 192.168.1.204 192.168.1.254 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.6.2 with 3 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.1.1 00:c0:9f:09:b8:db QUANTA COMPUTER, INC. 192.168.1.204 00:11:43:0f:f2:dd DELL INC. 192.168.1.254 00:60:5c:f4:c6:f4 CISCO SYSTEMS, INC.
Next we scan the same systems, but specify --destaddr=01:00:5e:00:00:05 to set the Ethernet destination address to the OSPF multicast address. Only the Cisco router responds, because that is the only system that is listening to the OSPF multicast address.
$ arp-scan --interface=eth0 --destaddr=01:00:5e:00:00:05 192.168.1.1 192.168.1.204 192.168.1.254 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.6.2 with 3 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.1.254 00:60:5c:f4:c6:f4 CISCO SYSTEMS, INC.
Detecting Promiscuous Mode Interfaces
First we scan three systems using the default options. The IP addresses are 192.168.1.1, 192.168.1.204 and 192.168.1.254, which are running Linux 2.6.19, Windows 2003 and Cisco IOS 12.2(29) respectively. All three systems respond as expected.
$ arp-scan --interface=eth0 192.168.1.1 192.168.1.204 192.168.1.254 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.6.2 with 3 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.1.1 00:c0:9f:09:b8:db QUANTA COMPUTER, INC. 192.168.1.204 00:11:43:0f:f2:dd DELL INC. 192.168.1.254 00:60:5c:f4:c6:f4 CISCO SYSTEMS, INC.
Next we scan the same systems, but specify --destaddr=01:00:01:02:03:04 to set the Ethernet destination address to an unassigned multicast address. Only the Linux system responds, because it is running tcpdump which has put its Ethernet interface into promiscuous mode.
$ arp-scan --interface=eth0 --destaddr=01:00:01:02:03:04 192.168.1.1 192.168.1.204 192.168.1.254 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.6.2 with 3 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.1.1 00:c0:9f:09:b8:db QUANTA COMPUTER, INC.
ARP Ethernet Frame Padding
ARP packets are only 28 bytes long, which is shorter than the minimum Ethernet frame length of 46 bytes. Therefore each ARP packet must be followed by at least 18 bytes of padding. If the ARP implementation doesn't pad the outgoing ARP frames, then the Ethernet driver must do so.
The diagram below shows an ARP packet within an Ethernet frame with padding to achieve the minimum Ethernet frame size.
arp-scan can add arbitary padding data to the outgoing ARP requests with the --padding option. If the --verbose option is specified, then arp-scan will report any non-zero padding on received ARP responses.
Most implementations will pad up to the minimum frame length with zero bytes, but not all implementations do this. Below are some examples of systems that return non-zero padding bytes:
$ arp-scan --interface=eth0 --padding=0102030405060708 --verbose 192.168.1.0/24 | grep Padding 192.168.1.147 00:11:24:84:a1:b2 Apple Computer Padding=555555555555555555555555555555555555 192.168.1.153 00:10:db:26:4d:52 Juniper Networks, Inc. Padding=888888888888888888888888888888888888 192.168.1.158 08:00:20:a0:09:a4 SUN MICROSYSTEMS INC. Padding=555555555555555555555555555555555555 192.168.1.190 00:00:aa:84:eb:0c XEROX CORPORATION Padding=01020304050607080000000000000000000000000000 192.168.1.192 00:30:c1:cd:3a:13 HEWLETT-PACKARD Padding=010203040506070800000000000000000000 192.168.1.249 00:90:27:57:c1:f3 INTEL CORPORATION Padding=000000000000000000000000000089322ba2 192.168.1.250 00:06:d7:55:0f:40 Cisco Systems, Inc. Padding=00000000000000000000000000000000000005060708
In the example above, the systems are:
| IP Address | Operating System | Notes |
|---|---|---|
| 192.168.1.147 | MacOS 10.4 | pads with 18 bytes of 0x55 (binary 01010101) |
| 192.168.1.153 | NetScreen ScreenOS 5.0.0 | pads with 18 bytes of 0x88 (binary 10001000) |
| 192.168.1.158 | Solaris 8/SPARC, qfe Ethernet | pads with 18 bytes of 0x55 (binary 01010101) |
| 192.168.1.190 | Xerox Phaser 6200 | re-uses the padding from the ARP request frame |
| 192.168.1.192 | HP JetDirect | re-uses the padding from the ARP request frame |
| 192.168.1.249 | Linux with eepro100 driver | adds four non-zero bytes at the end of the padding |
| 192.168.1.250 | Cisco Catalyst IOS 12.0 | adds part of the padding from the request frame |
I have not performed much investigation on ARP frame padding, and I suspect that there are more oddities waiting to be discovered.
802.2 LLC/SNAP Framing
By default, arp-scan sends ARP requests using Ethernet-II Ethernet framing, which is the standard Ethernet framing for TCP/IP. If the --llc (-L) option is specified, then arp-scan will send ARP requests using IEEE 802.2 LLC/SNAP Framing instead, as defined in RFC 1042 "Standard for the transmission of IP datagrams over IEEE 802 networks".
Irrespective of whether the --llc option is specified, arp-scan will always receive ARP responses in either Ethernet-II or 802.2 format, and will display "(802.2 LLC/SNAP)" to indicate an 802.2 format ARP response.
The 802.2 LLC/SNAP framing detailed in RFC 1042 is applicable to three underlying physical networks: 802.3 (Ethernet), 802.4 (Token Bus) and 802.5 (Token Ring). However the current version of arp-scan only supports Ethernet, and cannot be used for 802.4 or 802.5 networks.
The 802.2 LLC framing is obsolete, and is almost never seen on a real world network. But some network stacks still support it, especially routers, which need to be able to communicate with a diverse range of equipment, and operating systems with a history of use on networks using 802.2 LLC.
The following operating systems have been found to support ARP requests with 802.2 LLC/SNAP framing:
- Cisco IOS on routers and Catalyst switches (tested IOS 12.1 and 12.2).
- All versions of Windows (tested 95, NT4, 2000, XP, 2003, Vista).
Here is an example from Windows Vista SP1. Although Windows systems support ARP requests with SNAP framing, they respond with standard Ethernet-II framing.
$ arp-scan --llc 192.168.1.50 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.7 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.1.50 00:1d:09:94:3e:5f Dell Inc
Here is an example from a Cisco router running IOS 12.2. Cisco IOS will respond to an ARP request in SNAP format with an ARP reply in SNAP format.
$ arp-scan --llc 192.168.124.251 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.7.1 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.124.251 00:04:27:6a:5d:a1 Cisco Systems, Inc. (802.2 LLC/SNAP)
Other Techniques
Identifying secondary IP addresses
If two or more IP addresses respond with the same MAC address then, assuming it's not proxy ARP or an interface on a different network segment, this indicates that the IP addresses are on the same network interface.
Here is an example from a Linux system:
$ arp-scan --interface=eth0 192.168.1.68 192.168.1.69 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.5.2 with 2 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.1.68 00:0b:db:1c:59:e7 Dell ESG PCBA Test 192.168.1.69 00:0b:db:1c:59:e7 Dell ESG PCBA Test
And here is the interface configuration from the system that produced this output:
eth0 Link encap:Ethernet HWaddr 00:0B:DB:1C:59:E7
inet addr:192.168.1.68 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14874 errors:0 dropped:0 overruns:0 frame:0
TX packets:4822 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1274872 (1.2 MiB) TX bytes:361344 (352.8 KiB)
Interrupt:7
eth0:1 Link encap:Ethernet HWaddr 00:0B:DB:1C:59:E7
inet addr:192.168.1.69 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:7
Identifying interfaces on the same system
Systems with multiple interfaces often (but not always) have MAC addresses that are very close together. This is because the interface cards in a batch typically have sequential addresses. When a system is built, the interface cards are typically all sourced from the same batch. Also, multi-port network cards invariably have sequential MAC addresses for the individual ports.
Here is an example taken from the arp-scan output from six different scans on different Ethernet network segments:
192.168.4.94 00:a0:8e:33:81:f0 Nokia Internet Communications 10.5.40.2 00:a0:8e:33:81:f1 Nokia Internet Communications 192.168.4.30 00:a0:8e:33:81:f8 Nokia Internet Communications 192.168.5.30 00:a0:8e:33:81:fc Nokia Internet Communications 192.168.5.45 00:a0:8e:33:81:fd Nokia Internet Communications 192.168.5.145 00:a0:8e:33:81:ff Nokia Internet Communications
We can see that all six of the MAC addresses are very close together. They all belong to a single Nokia firewall, which connects the six networks.
Identifying Proxy ARP
Many routers will issue proxy arp replies for addresses that belong on a different interface. Cisco routers do this by default.
Here is an example of proxy ARP responses from a Cisco router. In this example, the network 172.18.0.0/28 is on a different Ethernet interface from the testing system.
$ arp-scan --interface=eth0 172.18.0.0/28 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.5.2 with 16 hosts (http://www.nta-monitor.com/tools/arp-scan/) 172.18.0.0 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.1 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.2 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.3 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.4 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.5 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.6 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.7 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.8 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.9 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.10 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.11 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.12 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.13 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.14 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.15 00:04:27:6a:5d:a1 Cisco Systems, Inc. 18 packets received by filter, 0 packets dropped by kernel Ending arp-scan 1.5.2: 16 hosts scanned in 0.655 seconds (24.43 hosts/sec). 16 responded
It's normally fairly easy to spot proxy ARP replies because:
- You get responses for all addresses in the IP network
- All responses use the same Ethernet MAC address
- The MAC address belongs to a router device
Because proxy ARP is enabled by default on some routers, you can use arp-scan to determine the IP networks behind these routers. This can be a useful network mapping technique, especially when the router blocks ping and traceroute traffic.
Load balancing protocol MAC Addresses
Load balancing and failover protocols including VRRP (Virtual Router Redundancy Protocol), HSRP (Hot Standby Routing Protocol) and WLBS (Windows NT Load Balancing Service) encode additional data within the MAC address. There are probably other protocols that do the same thing.
Here are the entries for these protocols from mac-vendor.txt:
# From RFC 2338: 00-00-5E-00-01-{VRID}
00005E0001 VRRP (last octet is VRID)
# Microsoft WLBS (Windows NT Load Balancing Service)
# http://www.microsoft.com/technet/prodtechnol/acs/reskit/acrkappb.mspx
02BF Microsoft WLBS (last four octets are IP address)
# Cisco HSRP (Hot Standby Routing Protocol)
# 00-00-0c-07-ac-XX
00000C07AC HSRP (last octet is group number)
When arp-scan displays MAC addresses associated with these protocols, you can determine additional information from the MAC address. For VRRP you can determine the VRID (Virtual Router IDentifier) from the last octet, and for WLBS you can determine the IP address from the last four octets.
Here are some examples of arp-scan output for VRRP IP addresses:
192.168.6.20 00:00:5e:00:01:65 VRRP (last octet is VRID) 192.168.6.227 00:00:5e:00:01:72 VRRP (last octet is VRID) 192.168.6.228 00:00:5e:00:01:40 VRRP (last octet is VRID)
In this example, the first IP address belongs to VRID 101 (0x65), the second to VRID 114 (0x72) and the last to VRID 64 (0x40).
If anyone is aware of any other protocols that store additional information in the MAC address, please let me know so that I can include them in mac-vendor.txt.
Linux IP Routing
Linux, like many other operating systems, will only respond to an ARP request if the IP address in ar$spa is within the IP network of the interface that the ARP is received on.
However, Linux also replies if the IP address in ar$spa is routed through the interface that the ARP request is received on. This allows you to determine the IP networks that are routed via a given interface on Linux, and any other operating systems that behave in the same way.
802.11 wireless networks
arp-scan works on 802.11 wireless (wifi) networks in exactly the same way as it does on conventional Ethernet networks, because wireless networks use the same Ethernet data-link protocol as normal Ethernet.
The reason wireless is specifically mentioned is because not everyone realises that arp-scan works on wireless networks.
The main differences when running arp-scan on wireless networks are:
- You need to associate with the network before you can start scanning.
- Wireless networks use MAC address filtering much more than wired networks do, so you might find that your MAC address is blocked. arp-scan lets you change the source MAC address in the Ethernet header with the --srcaddr option, and this is sometimes useful in these situations.
- Hosts on wireless networks are more transient than those on wired networks, so it's often worth scanning a few times with a time gap between scans.
Below is an example of arp-scan being used on an 802.11g wireless network. In this example we are scanning from a Linux laptop with a Proxim 802.11g card that is associated with a Linksys WRT54G access point.
$ iwconfig ath0
ath0 IEEE 802.11g ESSID:"what ever i want" Nickname:""
Mode:Managed Frequency:2.437 GHz Access Point: 00:12:17:C7:E0:E2
Bit Rate:48 Mb/s Tx-Power:31 dBm Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=61/94 Signal level=-37 dBm Noise level=-98 dBm
Rx invalid nwid:370 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
$ ifconfig ath0
ath0 Link encap:Ethernet HWaddr 00:20:A6:51:5E:51
inet addr:192.168.1.101 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9326 errors:0 dropped:0 overruns:0 frame:0
TX packets:10425 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3385479 (3.2 MiB) TX bytes:876041 (855.5 KiB)
$ arp-scan --interface=ath0 --localnet
Interface: ath0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.5.2 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.1.1 00:12:17:c7:e0:e0 Cisco-Linksys, LLC
192.168.1.102 00:13:02:34:26:c7 Intel Corporate
We can see that there are two hosts on the wireless network: the access point at IP address 192.168.1.1, and another laptop at 192.168.1.102.
Note that the discovered MAC address for the access point is not the same as the access point MAC address reported by iwconfig, although they are so close that they obviously belong to the same device. I suspect that the wireless ethernet interface on this AP does not actually have an IP address, but is bridged to the LAN interface which does.
Determining the interface netmask
Some systems only answer ARP requests where the address in ar$spa is within the IP network of the interface that the request is received on. You can use this behaviour to determine the interface netmask on these systems as follows:
- First discover the system's IP address - this gives you an address that is within the system's interface network;
- Next use the binary search algorithm to locate the lowest address in the interface network. For this search, use zero as the lower bound, and the interface IP as the upper bound;
- Finally use the binary search algorithm to locate the highest address, using the interface IP as the lower bound and 255.255.255.255 (0xFFFFFFFF or 4,294,967,295) as the upper bound.
An alternative method is to test network address bounds based on likely netmasks rather than using the general binary search technique.
Below is an example using a Cisco router as the target. In this example, the configuration of the router's Ethernet interface is:
interface Ethernet0 ip address 192.168.1.254 255.255.255.240
The arp-scan runs below show that the router will only respond when the address in the ar$spa field is within the connected IP network of the interface, including the network and broadcast addresses. In this example the IP network is 192.168.1.240/28, so the IP addresses within the network are 192.168.1.240 - 192.168.1.255 inclusive.
$ arp-scan --interface=eth0 --arpspa=192.168.1.239 192.168.1.254 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.5.2 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/) 2 packets received by filter, 0 packets dropped by kernel Ending arp-scan 1.5.2: 1 hosts scanned in 0.865 seconds (1.16 hosts/sec). 0 responded
$ arp-scan --interface=eth0 --arpspa=192.168.1.240 192.168.1.254 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.5.2 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.1.254 00:60:5c:f4:c6:f4 CISCO SYSTEMS, INC. 3 packets received by filter, 0 packets dropped by kernel Ending arp-scan 1.5.2: 1 hosts scanned in 0.618 seconds (1.62 hosts/sec). 1 responded
$ arp-scan --interface=eth0 --arpspa=192.168.1.255 192.168.1.254 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.5.2 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.1.254 00:60:5c:f4:c6:f4 CISCO SYSTEMS, INC. 3 packets received by filter, 0 packets dropped by kernel Ending arp-scan 1.5.2: 1 hosts scanned in 0.608 seconds (1.64 hosts/sec). 1 responded
$ arp-scan --interface=eth0 --arpspa=192.168.2.0 192.168.1.254 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.5.2 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/) 2 packets received by filter, 0 packets dropped by kernel Ending arp-scan 1.5.2: 1 hosts scanned in 0.863 seconds (1.16 hosts/sec). 0 responded
Discovering other interface addresses
Some systems will respond to ARP requests for any interface, not only the interface that the request was received on. For these systems we can use arp-scan to discover the IP addresses of any other interfaces they may have.
The ARP response from such systems will always use the MAC address of the local interface, not the remote one. This is a type of proxy arp that allows a host to reach any of the interface addresses of systems connected to the same network without requiring an IP route entry.
The example below shows the response from a Linux system with two ethernet interfaces:
$ arp-scan --interface=eth0 192.168.1.1 10.0.105.225 192.168.1.1 00:c0:9f:09:b8:db QUANTA COMPUTER, INC. 10.0.105.225 00:c0:9f:09:b8:db QUANTA COMPUTER, INC.
eth0 Link encap:Ethernet HWaddr 00:C0:9F:09:B8:DB
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5286713 errors:0 dropped:0 overruns:0 frame:0
TX packets:13479278 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1140473784 (1.0 GiB) TX bytes:4259317135 (3.9 GiB)
eth1 Link encap:Ethernet HWaddr 00:D0:B7:40:D1:61
inet addr:10.0.105.225 Bcast:10.0.105.255 Mask:255.255.255.224
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2673325 errors:0 dropped:0 overruns:0 frame:0
TX packets:2409354 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2218626602 (2.0 GiB) TX bytes:417690392 (398.3 MiB)
Here is another example, this time from a Cisco router that is using 802.1Q VLAN sub-interfaces:
$ arp-scan --interface=eth0 192.168.1.251 172.18.0.1 172.18.2.1 192.168.1.251 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.0.1 00:04:27:6a:5d:a1 Cisco Systems, Inc. 172.18.2.1 00:04:27:6a:5d:a1 Cisco Systems, Inc.
interface FastEthernet0/1.50 encapsulation dot1Q 50 ip address 172.18.0.1 255.255.255.0 ! interface FastEthernet0/1.100 encapsulation dot1Q 100 ip address 192.168.1.251 255.255.255.0 ! interface FastEthernet0/1.300 encapsulation dot1Q 300 ip address 172.18.2.1 255.255.255.0
Here is a negative example from a Solaris 9 system that does not exhibit this behaviour. In this case, the system only responds to the request for the local interface IP:
$ arp-scan --interface=eth0 192.168.1.150 10.0.0.1 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.2 (ether-scan-engine 1.3) with 2 hosts 192.168.1.150 08:00:20:a0:09:a4 SUN MICROSYSTEMS INC. 3 packets received by filter, 0 packets dropped by kernel Ending arp-scan: 2 hosts scanned in 0.749 seconds (2.67 hosts/sec). 1 responded
qfe0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.150 netmask ffffff00 broadcast 192.168.1.255
qfe1: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 3
inet 10.0.0.1 netmask ff000000 broadcast 10.255.255.255
So far, I know of the following operating systems that respond to ARP requests for remote interface addresses:
- Linux
- Cisco IOS
The following operating systems are known not to respond to ARP requests for remote interface addresses:
- Solaris
- Windows NT 4
Setting ar$spa to the destination address
|
WARNING: Setting ar$spa to the destination IP address can disrupt target system operation |
You can use the --arpspa=dest option to set the ar$spa field in the ARP request to the same IP address as the target. For single targets you could achieve the same effect by specifying the same IP address in the arpspa option and also the target IP address, but --arpspa=dest has the advantage that it works for multiple targets too.
Many systems interpret this as a promiscuous ARP, and assume there must be an IP address clash if they receive an ARP request for their own address. For this reason you should use --arpspa=dest with care, as it can disrupt some systems. In some ways this is an ARP version of the 1997-vintage LAND attack.
Here is an example of this against a Windows XP SP2 system. The windows system responds to the ARP request, but also logs an IP address conflict error.
$ arp-scan --interface=eth0 --arpspa=dest 192.168.124.11 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.5.2 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.124.11 00:0f:1f:5c:d1:13 WW PCBA Test
Debugging with --verbose
If you specify the --verbose option arp-scan will display additional debugging output, which can be useful in some circumstances. Here is an example:
$ arp-scan --interface=eth0 --verbose 192.168.1.0/29 Interface: eth0, datalink type: EN10MB (Ethernet) DEBUG: pcap filter string: "arp and ether dst 00:02:b3:bb:5c:11" DEBUG: Loaded 9978 IEEE OUI/Vendor entries from /usr/local/share/arp-scan/ieee-oui.txt. DEBUG: Loaded 1781 IEEE IAB/Vendor entries from /usr/local/share/arp-scan/ieee-iab.txt. DEBUG: Loaded 4 MAC/Vendor entries from /usr/local/share/arp-scan/mac-vendor.txt. DEBUG: pkt len=64 bytes, bandwidth=256000 bps, interval=2000 us Starting arp-scan 1.5.2 with 8 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.1.1 00:c0:9f:09:b8:db QUANTA COMPUTER, INC. 192.168.1.3 00:02:b3:bb:66:98 Intel Corporation 192.168.1.4 00:02:b3:bb:5c:09 Intel Corporation 192.168.1.5 00:02:a5:90:c3:e6 Compaq Computer Corporation 192.168.1.6 00:c0:9f:0b:91:d1 QUANTA COMPUTER, INC. --- Pass 1 complete --- Pass 2 complete 8 packets received by filter, 0 packets dropped by kernel Ending arp-scan 1.5.2: 8 hosts scanned in 0.895 seconds (8.94 hosts/sec). 5 responded
We can see that specifying the --verbose option has added the following additional items of information to the arp-scan output:
- The filter string use by libpcap to capture ARP responses: pcap filter string: "arp and ether dst 00:02:b3:bb:5c:11"
- The number of vendor string entries loaded from the OUI, IAB and MAC/Vendor files, and the locations of these files.
- The packet interval calculation for the desired output bandwidth.
- Details of when each pass is complete. In this example we see that all hosts have responded after the first pass, which is typical behaviour.
802.1Q VLAN Hopping
Specifying the --vlan (-Q) option causes an 802.1Q header containing the specified VLAN number to be added to the outgoing ARP request frames as shown in the diagram below.
Irrespective of whether the --vlan option was specified, arp-scan will always receive ARP replies either with or without an 802.1Q header, and will display "(802.1Q VLAN=<n>)" to indicate a response containing a 802.1Q header and show the VLAN number.
If the system running arp-scan is on a switch trunk port, then the --vlan option can be used to scan systems in any VLAN.
Writing responses to a PCAP Savefile
If the --pcapsavefile (-W) option is used, then the received ARP replies are written to the specified PCAP savefile in addition to being displayed in the normal way.
This option can be useful if you want to perform additional analysis on the received ARP responses.
Here is an example showing the use of the --pcapsavefile option, and analysis of the PCAP savefile with tcpdump.
$ arp-scan -I eth0 --pcapsavefile=arp-pcap 192.168.124.1 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.7 with 1 hosts (http://www.nta-monitor.com/tools/arp-scan/) 192.168.124.1 00:c0:9f:09:b8:db QUANTA COMPUTER, INC.
$ tcpdump -n -r arp-pcap reading from file arp-pcap, link-type EN10MB (Ethernet) 10:53:33.029285 arp reply 192.168.124.1 is-at 00:c0:9f:09:b8:db
Unusual Behaviour
Here is a list of strange behaviour that I've noticed while using arp-scan.
Duplicate ARP replies
Some systems have been observed to send multiple ARP responses to a single ARP request. arp-scan flags these duplicate responses as DUP: n in the output, where n is the number of times we've seen this reply.
Here is an example from an arp-scan against a Class-C network. The -N option is the short form of --nodns, which prevents any DNS lookups; and -r 1 is the short form for --retry=1, which ensures that only one ARP request is sent.
% arp-scan -N -r 1 -s 192.168.1.40 192.168.1.0/24 Interface: eth0, datalink type: EN10MB (Ethernet) Starting arp-scan 1.2 (ether-scan-engine 1.3) with 256 hosts 192.168.1.33 00:00:5e:00:01:ca USC INFORMATION SCIENCES INST 192.168.1.34 00:0b:46:e4:8d:6d Cisco 192.168.1.34 00:0b:46:e4:8d:6d Cisco (DUP: 2) 192.168.1.45 00:0a:b7:9b:b7:7a Cisco Systems 192.168.1.46 00:0a:b7:9b:b7:01 Cisco Systems
We see that the Cisco system with IP address 192.168.1.34 and MAC address 00:0b:46:e4:8d:6d responds twice to the single ARP request.
Here is the tcpdump output from another example:
00:0b:db:1c:59:e7 > ff:ff:ff:ff:ff:ff, ethertype ARP, length 42: arp who-has 192.168.1.99 tell 192.168.1.102
0001 0800 0604 0001 000b db1c 59e7 c0a8
0166 0000 0000 0000 c0a8 0163
00:e0:b6:06:9d:1d > 00:0b:db:1c:59:e7, ethertype ARP, length 60: arp reply 192.168.1.99 is-at 00:e0:b6:06:9d:1d
0001 0800 0604 0002 00e0 b606 9d1d c0a8
0163 000b db1c 59e7 c0a8 0166 0000 0000
0000 0000 0000 0000 0000 0000 0000
00:e0:b6:06:9d:1d > 00:0b:db:1c:59:e7, ethertype ARP, length 60: arp reply 192.168.1.99 is-at 00:e0:b6:06:9d:1d
0001 0800 0604 0002 00e0 b606 9d1d c0a8
0163 000b db1c 59e7 c0a8 0166 0000 0000
0000 0000 0000 0000 0000 0000 0000
Here the ARP request is sent, and the first reply comes back in 252us followed by a second reply 262us after the first. The vendor OUI for this device is "Entrada Networks".
I do not know what causes this behaviour, and suspect that it is a bug in the IP stack. If anyone knows the cause, please let me know.
Keeping the vendor data up to date
The data used to decode the vendor string from the Ethernet MAC address is kept in three files:
- ieee-oui.txt - IEEE OUI data
- ieee-iab.txt - IEEE IAB data
- mac-vendor.txt - Manual ARP/Vendor mappings
The first two of these are generated from the data on the IEEE website; the last one is manually maintained by the arp-scan author.
Each new release of arp-scan will contain updated versions of all three files. However you can also update them yourself between releases, and it is suggested that you update from time to time to ensure that the data is up to date.
You can update the first two files using the Perl scripts get-oui and get-iab, which are included in the arp-scan distribution.
To use these scripts, first change directory to the place where these files are stored. The exact location depends on what was selected when arp-scan was configured, but it is generally /usr/local/share/arp-scan or /usr/share/arp-scan. Ensure that you have write access in this directory (which normally means that you'll need to be root).
Then run the two scripts. If you specify the -v (verbose) option, then they will display progress messages. The scripts will rename any existing ieee-oui.txt or ieee-iab.txt files to .bak.
Below is an example of these scripts being run.
$ get-oui -v Renaming ieee-oui.txt to ieee-oui.txt.bak Fetching OUI data from http://standards.ieee.org/regauth/oui/oui.txt Fetched 1612386 bytes Opening output file ieee-oui.txt 10164 OUI entries written to file ieee-oui.txt $ get-iab -v Renaming ieee-iab.txt to ieee-iab.txt.bak Fetching IAB data from http://standards.ieee.org/regauth/oui/iab.txt Fetched 277016 bytes Opening output file ieee-iab.txt 1843 IAB entries written to file ieee-iab.txt
The latest mac-vendor.txt is available from the Arp-scan mac vendor file. This is a small text file, and it is updated less frequently than the IEEE-maintained files. You can cut and paste this file over your version if it is updated.
