If either of the the addresses are unknown or do not correspond to each other, the ARP Bomber treats the sending Ethernet address as a thief and the IP address as stolen. The ARP Bomber attempts to confuse the thief by answering its ARP Request with an incorrect ARP Response, claiming the stolen IP address is associated with a bogus hardware address. Optionally, the ARP Bomber can also attempt to confuse the ARP caches of additional target devices on the same physical network, by sending incorrect ARP Response messages to them as well.
Depending on the IP implementation on the thief, ARP Bomber may be able to completely disable IP service on that device. For some implementations, ARP Bomber may only be able to cause intermittent IP communication failures (depending on timing considerations), or may have no effect at all. ARP Bomber is not a complete or foolproof solution.
The ARP Bomber is intended to be used by a network administrator to identify misconfigured devices attached to an IP network, and to attempt to interfere with these devices IP service. Only run this software on a network for which you have administrative responsibility.
ARP Bomber is a product of the Network Systems Group at Princeton University’s Office of Information Technology, and is available from http://www.net.princeton.edu/software/arp_bomber/
Presently the product builds and runs on Solaris 9 on SPARC with gcc. The program relies on the pcap(3), libnet(3), and the BIND resolver(3) libraries.
The ARP Bomber is looking for ARP Request packets in which the Sender Protocol Address is not in DNS, the Sender Hardware Address is not in the ethers(4) database, or the two addresses do not correspond to each other (more details about this is in the ANALYSIS ALGORITHM section below). When it finds such an ARP Request, it treats the Sender Hardware Address as a thief; the Sender Protocol Address is the stolen IP address.
We "bomb" the thief (assuming the -k option has been specified) by sending a bogus ARP Response packet to it. To construct the ARP Response, the Sender Protocol Address and Sender Hardware Address from the ARP Request packet are copied into the Target Protocol Address and Target Hardware Address fields, and the Target Protocol Address from the ARP Request packet is copied into the Sender Protocol Address field, just as in any normal ARP Response. But the ARP Response packet’s Sender Hardware Address is set to a bogus hardware address. (There are several different values all ending with "de:ad"; which one is used depends on the reason the ARP Bomber feels the client is a thief.) As with a normal ARP Reponse packet, the bogus ARP Response is unicast to the sender of the original ARP Request.
(Note that before sending an ARP Response to the thief, we check if the thief’s hardware address is an Ethernet group address. (An Ethernet address is a group address if the least-significant bit of the most-significant byte is 1.) If so, the ARP Bomber suppresses the ARP Response packet that would normally be sent to the thief; we do not wish to send an ARP Response that will be seen by devices other than the thief.)
The intended result of the bogus ARP Response is to confuse the thief. If the thief was trying to communicate with some other device foo on the local network, the ARP Bomber may have polluted the thief’s ARP cache, possibly disrupting the thief’s ability to communicate with foo. Naturally, whether the ARP Bomber succeeds will depend on whether the thief also receives a valid ARP Response from foo. Typical ARP implementations use a "last in wins" approach; once an ARP cache entry exists for a specific IP address, later ARP Response packets for this IP address may overwrite the hardware address specified by earlier responses. Since this is entirely timing-dependant, sometimes it works, and sometimes it fails.
The ARP Bomber is most effective when the thief’s ARP Request packet isn’t for some other device with which it hopes to communicate, but instead is a Gratuitous ARP request for its own IP address. Many IP stacks issue a Gratuitous ARP request while starting up, as a way to verify that no other device on the network is already using the IP address they intend to use for themselves. In this situation, the client broadcasts an ARP Request for its own IP address, expecting that no one will respond. When the ARP Bomber responds, this should upset the device; ideally the thief will log some sort of error about the IP address already being in-use by another device, and shut down its own IP stack. The ARP Bomber is most effective when the thief’s IP stack functions this way. Some IP stacks will only log the error, but continue to function. Some IP stacks will not log any error, and some will not even issue a Gratuitous ARP in the first place. The ARP Bomber will not be able to effectively shut down the latter flavors of IP stacks.
Optionally, you can configure the ARP Bomber with additional targets. Each additional target is some other device (on the bomber network) which provides some critical IP service to devices on that network. (Ideal choices are IP routers. Other choices might include Web servers, DNS servers, etc.) When the ARP Bomber decides to bomb a thief, it will also send ARP Response packets to the additional targets (assuming you specify the -g option). These are also ARP Response packets, with the Sender Protocol Address set to the stolen IP address, and the Sender Hardware Address set to the bogus hardware address.
The purpose of the ARP Response packets sent to the additional targets is to confuse the additional target devices (e.g. IP routers) so that they cannot send traffic to the stolen IP address. In the case of an IP router, this would prevent the thief from receiving IP packets from off-network devices.
The use of additional targets is particularly attractive, since it can work even if the thief has survived the ARP Response we sent directly to him.
The additional targets feature still isn’t foolproof. At best, it prevents the additional targets from sending packets to the stolen IP address; but it does not prevent the thief from sending packets to the additional targets. Moreover, an additional target device may ignore the bogus ARP Response we send it; it might only listen to the packet if it has recently issued an outstanding ARP Request for the stolen IP address, or already has an ARP cache entry for the stolen IP address. Additionally, following the "last in wins" approach, if the additional target device hears any more ARP Request or ARP Response packets from the thief, it will likely overwrite the bogus hardware address learned from the ARP Bomber with the thief’s hardware address, restoring its ability to send packets to the thief. Finally, the additional target will eventually time out the bogus ARP cache entry entirely, cancelling the effect of the ARP Bomber.
If the Sender Protocol Address is zero, the ARP Bomber will ignore the packet. (However, this behavior may be modified, see the "ARP PROBE PROCESSING" section below.)
If the Sender Protocol Address is 255.255.255.255, the ARP Bomber will ignore the packet; we would not wish to issue a bogus ARP Response that claimed to associated a bogus hardware address with this IP address.
If the Sender Protocol Address is exempt (as specified in the arp_bomber.cf(5) file), the packet is ignored. Otherwise, if the Ethernet Source Address is exempt (as specified in the arp_bomber.cf file), the packet is ignored.
The Sender Hardware Address is looked up in ethers(4), using ether_ntohost(3). (Depending on the operating system configuration, this might result in a lookup into a static /etc/ethers file, or perhaps an NIS lookup in the ethers.byaddr map. If the ether_ntohost(3) lookup fails, and the mini_db_server facility is being used, the lookup is retried using that facility.
If the Ethernet Source Address is known, and the Sender Protocol Address is exempt when the Ethernet Source Address is known (as specified in the arp_bomber.cf(5) file), the packet is ignored.
The Sender Protocol Address is looked up in DNS. This is a true DNS lookup, using the gethostbyaddr(3) call provided by the ISC BIND resolver(3) library. It is not the gethostbyaddr(3) call provided by the operating system, as that may rely on some combination of NIS, static files, DNS, or some other mechanisms. Because some of those mechanisms can behave in unusual ways, ARP Bomber wants to rely on true DNS. Ensuring that BIND’s own gethostbyaddr(3) routine is used is done by linking the ARP Bomber against libbind, the resolver library provided as part of ISC BIND.
If the Sender Protocol Address is not found in DNS, packet analysis stops; the ARP Bomber assigns the client an "IP-UNKNOWN" status, and proceeds to the bombing phase.
If the Sender Hardware Address was not found (the lookup was done earlier), packet analysis stops; the ARP Bomber assigns the client an "ETHER-UNKNOWN" status, and proceeds to the bombing phase.
If the Sender Hardware Address was found, the value (a hostname) is saved as ether_sender_name.
If ether_sender_name ends with a dot, it is deemed to be a fully-qualified DNS hostname. Otherwise, if it ends with the default DNS domain name specified in arp_bomber.cf(5), it is made fully-qualified by appending a dot to it. Otherwise it is made fully-qualified by appending a dot, the default DNS domain name, and another dot.
The ether_sender_name is looked up in DNS (again, this is a true DNS lookup, this time using gethostbyname(4).) If ether_sender_name is not found (and the lookup returned without an error), then this is interpreted to mean that although the Ethernet address was known, this Ethernet address is not permitted to use any IP address. We assign the client a "MISMATCH" status, and proceed to the bombing phase.
If ether_sender_name was found in DNS, the ARP Bomber examines the IP address(es) returned by DNS. If any one of them matches the Sender Protocol Address, we declare that the client’s Ethernet address and IP address "match"; no bombing is necessary. Otherwise (when no returned IP address is the Sender Protocol Address), we assign the client a "MISMATCH" status, and proceed to the bombing phase.
This concludes the packet analysis; if the client was assigned an "IP-UNKNOWN", "ETHER-UNKNOWN", or "MISMATCH" status, we arrived at the bombing phase, treating the Sender Hardware Address as a thief, and the Sender Protocol Address as a stolen IP address.
Given this approach, if you have devices with multiple Ethernet addresses, or multiple IP addresses, you’ll need to give careful thought to how you enter them into your ethers(4) database and your DNS data. It’s easy to handle a device that has a single Ethernet address but multiple IP addresses; the single Ethernet address goes into the ethers(4) database with name "foo.example.org", and in DNS you create an A-record for each of the IP addresses, each labelled "foo.example.org." Although the ARP Bomber will allow the device to use any of its IP addresses on your network (even those not appropriate for this particular IP network), you’ll probably find this is what you want, especially if the client’s IP stack uses a weak-end model when sending IP packets.
If you have a device with multiple Ethernet addresses, you may not be able to make it function with the ARP Bomber, since the ethers(4) database requires a unique one-to-one mapping between Ethernet addresses and names (at least if it implemented via NIS). You may be able to work around this by pretending each Ethernet address/IP address combination is a different host, but for most cases, you’ll find this simply isn’t feasible. The fundamental assumptions on which the ARP Bomber are based generally don’t work well if you must support hosts with multiple Ethernet addresses. You may need to simply exempt those devices from the ARP Bomber entirely.
If the client’s status is "IP-UNKNOWN", the bomber selects the bogus hardware address 0:0:0:0:de:ad. If the client’s status is "ETHER-UNKNOWN", the bomber selects the bogus hardware address 0:dd:dd:dd:de:ad. If the client’s status is "MISMATCH", the bomber selects the bogus hardware address 0:ee:ee:ee:de:ad.
The bogus hardware address the ARP Bomber decides to use is known as the dead address; all of these hardware addresses end with the hexadecimal bytes "de:ad". The intent is to provide some clue to the victim of the ARP Bomber that all is not well.
To enable the feature, you must specify the -g command-line option, and also specify one or more additional_target statements in the arp_bomber.cf(5) file.
Even when the feature is enabled, the ARP Bomber performs some additional tests before sending ARP Response packets to any additional targets; there are a number of situations where these packets should be suppressed:
The bomber first checks to see if the stolen IP address falls within the IP network range(s) associated with the bomber network. (It does this by comparing the IP address with the network ranges specified by the network statement(s) in the arp_bomber.cf(5) file.) If the stolen IP address does not fall within any of these network ranges, ARP Response packets to all additional targets are suppressed. This is for several reasons: firstly, the ARP Bomber doesn’t need to confuse additional targets about this particular IP address, since they wouldn’t try to communicate with this IP address on this physical network anyway (assuming IP routing is properly configured). Secondly, if we were to confuse an additional target, and the stolen IP address happens to fall into a network range directly attached to one of the additional target’s other physical interfaces, we might prevent the additional target from communicating with the legitimate owner of this IP address.
Next, the bomber checks to see if the stolen IP address is the same as any IP address declared as an additional target. If so, ARP Response packets to all additional targets are suppressed. Clearly we must not send the ARP Response packet to the one additional target that is the legitimate owner of the stolen IP address; this would confuse this legitimate owner. Although it might be acceptable to send the ARP Resonse packets to the other additional targets, we choose not to, on the assumption that all the devices declared as additional targets are crucial network infrastructure that need to be able to communicate reliably with each other. We don’t want to pollute the ARP cache entries they use to talk amongst themselves.
Next, the bomber checks to see if the stolen IP address is specified as an additional_target_suppress_add entry in the arp_bomber.cf(5) file. You typically use this optional statement to specify all flavors of the IP broadcast address valid for all IP networks running on the ARP Bomber network. (If a thief claims to own the IP broadcast address, we must not send an ARP Response to the additional targets claiming that we own the broadcast address; that could only make matters worse.) You might also list the IP addresses of other critical services with which the additional target devices always must be able to communicate. For example, if the additional target devices included IP routers, and they obtain their firmware from a TFTP server located on the bomber network, you might wish to specify the TFTP server’s IP address as an additional_target_suppress_add item. This way, if a client steals the TFTP server’s IP address, the bomber will not try to convince the IP routers that the hardware address for their TFTP server is a dead address.
Note that there is no reason to specify any IP address as both an additional_target and an additional_target_suppress_add item; every members of the additional targets list is treated as an implicit member of the additional target suppress adds list.
Note that there is no no reason to specify any off-network IP address as an additional_target_suppress_add item; when a client steals one of these IP addresses, no ARP Response packets would be sent to the additional targets.
The next check performed by the ARP Bomber is to see if the stolen IP address is a Class D (IP multicast) address. If so, ARP Response packets to all additional targets are suppressed. We don’t want to pollute our additional targets’ ARP caches with bogus hardware addresses for IP multicast destinations.
If the stolen IP address was found in DNS earlier (the client status is either "ETHER-UNKNOWN" or "MISMATCH"), a final check performed by the ARP Bomber is to determine if the legitimate owner of the stolen IP address is presently live on the bomber network. If the legitimate owner is alive, we do not wish to send ARP Response packets to the additional targets, because we could interfere with IP service to the legitimate owner of the IP address. (Note that the legitimate owner may already be experiencing difficulty due to the thief. We cannot fix that, but we should at least not exacerbate it.)
To determine if the legitimate owner of a stolen IP address is alive, the ARP Bomber causes the bomber host to issue an ARP Request for the stolen IP address, then checks to see it received a response from the legitimate owner of the stolen IP address. (The legitimate owner is determined through a matching between DNS and ethers(4) equivalent to that described in the "ANALYSIS ALGORITHM" section earlier.)
When performing the "Is the Legitimate Owner Alive" check, the bomber doesn’t actually issue an ARP Request itself and listen for ARP Response packets. Instead, it forces the bomber host’s operating system to do this, by clearing the operating system’s ARP cache entry for the stolen IP address, then attempting to send a packet to the stolen IP address’ UDP/discard port. After attempting to send the packet, the ARP Bomber checks the operating system’s ARP cache for the stolen IP address, to determine what hardware address on the network (if any) responded. If it finds no ARP cache entry (or the entry specifies a hardware address other than the legitimate owner of the stolen IP address), it retries a few times. If it ever finds an ARP cache entry from the legitimate owner of the stolen IP address, it suppresses the ARP Response packets that it would otherwise send to all the additional targets.
The "Is the Legitimate Owner Alive" check is far from perfect. It only works if the legitimate owner is alive and responding at the time of the test. Also, because the ARP Bomber simply uses the host’s ARP cache to perform the test (rather than sending and receiving ARP packets itself), it is subject to the "last response wins" behavior; if both the legitimate owner and a thief respond to the operating system’s ARP Request, but the thief responds after the legitimate owner and before the ARP Bomber checks the ARP cache, the bomber will only know that the thief responded. (Note that the test does not rely on the legitimate owner being able to respond to the UDP/discard packet. That packet is only sent to stimulate the bomber host’s operating system to issue an ARP Request.)
It is possible the legitimate owner of the stolen IP address will attach to the network after the test is done and the additional targets have been confused. However, this is not as serious a problem as it might seem; when the legitimate owner issues its own ARP Requests (or Gratuitous ARP Request at startup), an additional target will typically use these to overwrite the bogus ARP cache entry it learned from the ARP Bomber.
Whenever the ARP Bomber receives an ARP Request, it compares the Sender Protocol Address to any exempt IP clients; if it matches, the ARP Bomber stops analyzing the packet and ignores it. If it does not match, the ARP Bomber compares the source Ethernet address to any exempt Ethernet clients; if it matches, the ARP Bomber stops analyzing the packet and ignores it. If it does not match, the ARP Bomber looks up the Sender Hardware Address in the ethers(4) database; if it is found, the ARP Bomber then compares the Sender Protocol Address to any exempt IP when Ether Known clients; if it matches, the ARP Bomber stops analyzing the packet and ignores it.
Clients you might want to specify as exempt might include any that cannot meet the fundamental assumptions made by the ARP Bomber; e.g. that the client’s Ethernet address appears in the ethers(4) database, the client’s IP address appears in DNS, and the name returned by the ethers database, once DNS-qualified, is found in DNS with an IP address corresponding to the one the ARP Bomber sees.
Keep in mind that if users become aware of Ethernet addresses or IP addresess that are exempt from the ARP Bomber, they could configure their devices to use these addresses, to evade the bomber. For this reason, you may wish to limit access to the ARP Bomber configuration file. If running the ARP Bomber with the debuglevel set high enough that exempt clients are displayed in the log, you may wish to limit access to the log as well.
RFC 2131 (Dynamic Host Configuration Protocol, section 4.4.1) describes a different sort of ARP Request that a DHCP client "SHOULD" use to probe a newly-leased IP address before using the address. This ARP Request contains a zero in the Sender Protocol Address field, to avoid confusing ARP caches in other hosts on the network. The newly-leased IP address will appear in the Target Protocol Address field.
This sort of ARP Requests is also proposed in draft-ietf-dhc-ipv4-autoconfig (Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network, section 3.1) , where it is called an ARP Probe.
In theory, the ARP Bomber can ignore ARP Probes. After completing the ARP Probe, the client will still need to use ARP Request packets to resolve local IP addresses; those ARP Requests will be "normal" ones (the Sender Protocol Address field will be non-zero), so the ARP Bomber will catch the device at that time. However, you might want the ARP Bomber to attempt to process the ARP Probe packets anyway; one reason would be if you’d like the ARP Bomber to try to shut down the IP stack as soon as possible, in the same way it sometimes can by responding to a client’s Gratuitous ARP Request. Since clients that use ARP Probes might not ever send a Gratuitous ARP Request, the ARP Probe might be the bomber’s only opportunity to completely shut down the client’s IP stack.
By default the ARP Bomber will ignore ARP Probe packets (any ARP Request where the Sender Protocol Address is zero). To cause the ARP Bomber to attempt to process ARP Probe packets, specify the -P option. When processing an ARP Probe packet, the ARP Bomber will examine the Target Protocol Address field; if it is non-zero, it will pretend that the Sender Protocol Address field contained this value. (If the Target Protocol Address field is also zero, the ARP Bomber will ignore the packet; there is no well-defined meaning to an ARP Request in which both the Sender and Target Protocol Address fields are zero.)
Beware that enabling processing of ARP Probe packets could conceivably cause a problem. If bombing a client that issued an ARP Probe simply causes the client to try other IP addresses ad infinitum, the ARP Bomber and the client will get into an war, generating a large volume of ARP traffic on the network.
Some operating systems will not allow you to spoof your Ethernet address. In these situations, our ARP Response packets will contain the bomber host’s own Ethernet address as the Ethernet source address. This is fine; the ARP Bomber doesn’t need to be able to spoof its Ethernet address. The recipient of the ARP Response cares about the Sender Hardware Address carried inside the packet, not the source of the Ethernet frame.
If your operating system complains because the ARP Bomber tries to spoof its Ethernet source address, you may disable this feature via a compile-time definition.
The mini_db_server is a daemon that reads a flat ethers.byaddr-style map, and provides lookup service, tranlating Ethernet addresses to hostnames. The daemon is supplied along with the ARP Bomber program, and is implemented as a Perl script. You need to arrange to have the mini_db_server started before the ARP Bomber starts. It creates a UNIX domain socket using a pathname you specify to the script, and listens for requests on that socket. It is an iterative server, responding to requests from that socket.
The mini_db_server obtains its information from a flat ethers.byaddr-style file which you specify to the script. It checks the file’s modification time at an interval you specify, or whenver it receives a SIGHUP, re-reading the file when it discovers it has changed.
To help you maintain this file, the pull-nis-map script is also supplied. This is another daemon, implemented in Perl. It periodically uses ypcat(1) to obtain a copy of the ethers.byaddr NIS map, and saves it in a location you specify (if the data has changed).
Once the mini_db_server is operational, you can instruct ARP Bomber to use it by specifying the -m mini_db_server_pathname option; the mini_db_server_pathname you specify must be the same value that was specified to the mini_db_server daemon. The ARP Bomber will contact the mini_db_server by connecting to that UNIX domain socket.
The ARP Bomber will only contact the mini_db_server when ether_ntohost(3) is unable to locate an Ethernet address; it is intended as a backup facility.
When using this facility, you must also specify the -M mini_db_client_pathname option; this tells the ARP Bomber to bind to the specified UNIX domain socket. This is to provide a place for the mini_db_server to send its responses.
When the mini_db_server binds its UNIX domain socket to mini_db_server_pathname, there is a race condition that could force the mini_db_server to overwrite the current contents of mini_db_server_pathname. Therefore, you should specify a value so that it is located within a directory to which others do not have write-access.
Similarly, when the ARP Bomber binds its UNIX domain socket to mini_db_client_pathname, there is a race condition that could force the ARP Bomber to overwrite the current contents of mini_db_client_pathname. Therefore, you should specify a value so that it is located within a directory to which others do not have write-access.
Both mini_db_server_pathname and mini_db_client_pathname need to be readable and writable by both the ARP Bomber and the mini_db_server.
Each of mini_db_server_pathname and mini_db_client_pathname is typically limited in length to 104 or 108 bytes, based upon the operating system’s definition of a struct sockaddr_un.
The interface on which it listens is an Ethernet interface. (The ARP Bomber does not presently support FDDI interfaces.)
All ARP Request broadcasts reach the interface on which the bomber runs; there’s no layer 3 switching or broadcast suppression on the network which might prevent us from seeing broadcast ARP Request packets.
The host on which the ARP Bomber runs can perform both the ethers(4) database and DNS lookups fast enough so it can bomb a target while the target still listening for a response to its ARP Request.
Both your ethers(4) and DNS services never return a "false negative" for an address or name that is legitimate on the network on which the ARP Bomber runs. (If the lookup service is down, so it fails to return the value for a lookup, we will end up bombing the device even though it may be legitimate.)
Every non-exempt IP address on the ARP Bomber network can be found in DNS.
Every non-exempt hardware address on the ARP Bomber network can be found in ethers(4).
You use the same naming convention for DNS names and ethers(4) names (modulo a single static default DNS domain name specified in the arp_bomber.cf(5) file). For example, if we look up Ethernet address 0:1:2:3:4:5 in the ethers database and get a name of foobar.example.org then we should be able to lookup the hostname foobar.example.org. in DNS to get back the IP addres(es) that this Ethernet address is permitted to use. (Assuming you specify a default DNS domain name of example.org in the configuration file, then if the ethers database value does not end with a dot or with example.org, then before we look it up this name in DNS, we will append .example.org. (The ARP Bomber adds the leading and trailing dots). I.e. we can support names in the ethers database which are not fully-qualified, as long as all of them are relative to the single static DNS domain you specified in the configuration file.
If the ARP Bomber network has multiple IP networks running on it and you have configured the ARP Bomber with any additional_target devices, the ARP Bomber host must be configured to have a (virtual) interface on each of these multiple IP networks. Part of the additional_targets processing involves checking to see if the legitimate owner of the stolen IP address is also alive on the network. To do this, the ARP Bomber must be able to clear any IP ARP cache entry (on the host running the bomber) for the stolen IP address; the bomber also expects that if it can succesfully communicate with the stolen IP address, it will find the ARP Bomber host’s operating system has populated its ARP cache with an entry for the that IP address. Both of these expectations are typically met only if the host running the bomber believes it is on the same logical IP network as the stolen IP address; the host’s OS typically bases this belief on the (physical and virtual) interfaces configured on this host.
The host running the bomber must be able to keep up with the volume of packets that it must analyze. Although the filter used with pcap(3) specifies only ARP packets should be passed to the bomber, on systems where bpf isn’t part of the kernel, libpcap must implement bpf as part of the application. Also, although the ARP Bomber does not put the Ethernet interface into promiscuous mode, the interface might have been into that mode by other software on your host, increasing the number of packets the ARP Bomber must examine. The program is single threaded. If it can’t keep up with the packets coming in, it won’t be useful. (Remember that for every ARP Request, it must perform the ethers(4) and DNS lookups.)
The following message indicates that an ARP Request packet was received from an Ethernet address which has been specified as exempt via the exempt_ether statement in the arp_bomber.cf(5) file:
EXEMPT-ETHER: client_ether
The client-ether is replaced with the client’s Ethernet address.
This message is produced when the debuglevel is greater than 0. It’s sent at syslog level LOG_INFO.
You may suppress this message on a per-client basis using the hide flag in the exempt_ether_client statement.
The following message indicates that an ARP Request packet was received with a Sender Protocol Address which has been specified as exempt via the exempt_ip_client statement in the arp_bomber.cf(5) file:
EXEMPT-IP: client-IP
The client-IP is replaced with the client’s IP address.
This message is produced when the debuglevel is greater than 0. It’s sent at syslog level LOG_INFO.
You may suppress this message on a per-client basis using the hide flag in the exempt_ip_client statement.
The following message indicates that an ARP Request packet was received with a Sender Hardware Address found in ethers(4), and a Sender Protocol Address which has been specified as exempt via the exempt_ip_client_when_ether_known statement in the arp_bomber.cf(5) file:
EXEMPT-IP-WHEN-ETHER-KNOWN: client-IP , ether: client-ether , name: client-ether-name
The client-IP is replaced with the client’s IP address. The client-ether is replaced with the client’s Sender Hardware Address. The client-ether-name is replaced with the name found in ethers(4), for the client’s Sender Hardware Address.
This message is produced when the debuglevel is greater than 0. It’s sent at syslog level LOG_INFO.
You may suppress this message on a per-client basis using the hide flag in the exempt_ip_client_when_ether_known statement.
The following message indicates that an ARP Request packet was received and that the ARP Bomber decided the client’s status is one of: ETHER-UNKNOWN, IP-UNKNOWN, or MISMATCH:BOMB: ETHER=client_ether (client_ether_name) IP=client_ip (client_ip_name) REASON=client_status KILLER=thief_sent_code ADDITIONAL=additional_targets_sent_code [ future_text ]
The BOMB message is produced when the debuglevel is greater than 0. It’s sent at syslog level LOG_INFO.
The client_ether is the client’s Ethernet address (the Ethernet Source Address) and the client_ether_name is the name found in the ethers(4) database for this Ethernet address, if any. (If no name was found, then the parentheses appear with no name in them.)
The client_ip is the client’s claimed IP address (Sender Protocol Address). (If you have enabled ARP Probe Processing, client_ip reflects the Sender Protocol Address after ARP Probe Processing has been performed; i.e. this value may actually have been the Target Protocol Address in the ARP Request packet.) The client_ip_name is the name found in DNS for this IP address, if any. (If no name was found, then the parentheses appear with no name in them.)
The thief_sent_code indicates whether an ARP Response packet was sent to the thief, and if not, why not. A value of "sent" indicates that an ARP Response was sent to the thief; all other values indicate that no ARP Response was sent to the thief. The value "disabled" indicates the -k option was not specified. The value "suppressed_ethermcast" indicates the thief’s Ethernet address is a group address.
The additional_targets_sent_code indicates whether any ARP Response packets were sent to additional targets, and if not, why not. A value of "sent" indicates that an ARP Response was sent to additional targets; all other values indicate that no ARP Responses were sent to additional targets. The value "disabled" indicates the -g option was not specified. The value "suppressed_notargets" indicates that no additional targets were specified in the arp_bomber.cf(5) file The value "suppressed_istarget" indicates that the stolen IP address is also an additional_target . The value "suppressed_suppressadd" indicates that the stolen IP address is also an additional_target_suppress_add item. The value "suppressed_ipmcast" indicates that the stolen IP address is an IP multicast (Class D) address. The value "suppressed_ownerlive" indicates that the legitimate owner of the stolen IP address is presently live on the network. The value "suppressed_offnetwork" indicates that the stolen IP address does not fall within the IP network range(s) specified by the network statement(s) in the arp_bomber.cf(5) file.
The future_text field indicates that it is possible that the BOMB message might be extended in the future to have additional fields at the end. If parsing this message, you should be prepared to ignore those fields.
The original version was written by Michael Gettes. It was a modified version of Sun’s proxyarpd(8) for SunOS 4.x. That version supported the NIT (Network Interface Tap) facility in SunOS 4.1.4, functioning with a Lance Ethernet (le) or Intel Ethernet (ie) physical interface.
The current ARP Bomber was written by Irwin Tillman. It was rewritten to run on Solaris 9, relying on the generally-available pcap(3), and libnet(3) libraries, instead of NIT. It no longer includes any code from Sun’s proxyarpd(8) program.
The message "clear_arptab_entry: ioctl(SIOCDARP): No such device or address" is logged during normal operation. When we wish to send an ARP Response packet to any additional_target devices, we perform the "Is the Legitimate Owner Alive" check first. This check involves deleting the stolen IP address from our own ARP cache. The message above is normal if the stolen IP address didn’t happen to already be in our ARP cache; in this situation, the message is of no concern. However, because the same error is also returned by the operating system when we encounter a serious problem performing the ARP delete operation, the ARP Bomber cannot distinguish between the two cases. To be safe, we log the message.
Because we use ethers(4) to map from an Ethernet address to a hostname, and that database only supports a one-to-one mapping, we are unable to support clients that have multiple Ethernet addresses. Ideally we’d use a different database which either mapped from an Ethernet address to all valid DNS hostnames (a one-to-many mapping), or a database that maps directly between Ethernet addresses and IP addresses (a many-to-many mapping).
We do not support FDDI interfaces at this time.
We support only a single default DNS domain name for use when qualifying names returned from the ethers(4) database.
arp_bomber.cf(5)