8

I am wondering if it is possible to paralyze a network by sending out a bunch of fake ARP response packets.

Some basis: I recently read a moderately detailed description of how ARP and ARP poisoning works (which is here, pdf). I think I understand how ARP poisoning works, at least in the level of detail presented in that article.

My question is about a different type of ARP poisoning. Instead of sending ARP response packets that direct all traffic to the attacking computer, could a device send out ARP packets that just jumble the victim devices' ARP caches? It sends out many packets to each device on the network that give a wrong MAC address for every IP the attacking device can find?

Is this type of attack possible? What countermeasures are there against it? Are these countermeasures in common use?

Additional questions: Do ARP packets contain information that would allow the administrator of the network to locate a hidden wireless attacking device? Would there be a way to disconnect the device from the network?

Improve this question

4 Answers 4

Reset to default
5

It sounds plausible to me, though local-network denial-of-service attacks are rare simply because the offending device can be easily unplugged.

Through rather than seeing random ARP traffic, you're much more likely to see a device configured for Proxy ARP, just stealing all network traffic. This is an even easier attack to mount since most routers have the functionality already built in.

But again, it's uncommon to see DOS attacks on local networks; usually it's a matter of misconfiguration.

EDIT: In response to additional questions:

ARP packets contain the sender MAC, the destination MAC, and the target IP address (plus some bookkeeping). As with all network packets, every last bit can be spoofed. Assuming nothing malicious, you'll at least get the sender MAC address, the first few bytes of which are vendor-specific, and which you can look up to determine the vendor who made the network adapter. This could help identify the device. Of course, it can be spoofed, so don't depend on it.

As for WiFi networks, "open" unencrypted networks are something of an "anything goes" environment as far as security is concerned, so securing it is almost not worth the effort. However, if any form of encryption is enabled, then individual clients can only communicate with the router, not peer-to-peer, which means that the router can filter out noise like this.

Improve this answer
2
  • Thanks for the response. I will update the OP to reflect these additional questions, but what if this was a wireless device performing the attack? Do ARP packets contain information that would allow the administrator of the network to locate a hidden wireless device? Would there be a way to disconnect the attacking device from the network?
    – Grady S
    Dec 8, 2011 at 1:59
  • A managed switch will be able to tell you which port the offending MAC address is currently on. A building plan should be able to provide enough information to figure out which room that drop goes to -- assuming it hasn't been spliced in the middle and hidden somewhere (e.g. above the plenum).
    – Mark E. Haase
    Feb 7, 2012 at 19:09
6

This is actually called ARP flooding. An infected system/malicious user sends ARP replies to all systems connected to the network, filling them with incorrect ARP entries. This causes the systems to be unable to solve MAC and IP addresses resulting in systems being unable to connect to other systems in the network.

Improve this answer
3
  • Ahh. I saw something about ARP flooding earlier and I guess I thought it was different than what I was asking about. Thanks! Is it possible to find the MAC address or any other identifying information about the attacker?
    – Grady S
    Dec 8, 2011 at 5:52
  • You could look at the mac address tables on your switches to identify the port where the bogus MACs are coming from.
    – Paul Ackerman
    Dec 8, 2011 at 13:56
  • 2
    Actually I think ARP flooding originally was used as an attack against the switch. By flooding the switch MAC table with bogus entries, the real entries will be purged from the table, and the switch will in essence begin to act like an old hub, allowing everyone to listen to everyone else packets.
    – bjarkef
    Dec 16, 2011 at 6:41
5

To address the question "what countermeasures are available", dot1x authentication is probably the best way of securing the physical layer of the network. This will prevent these types of physical and data-link layer attacks by requiring hosts to authenticate to the network before they are allowed to transmit data. The switch will still see the bad mac addresses coming from the attacker but they will not reach any other switch or any of the other hosts on the network so the harm that can be done is significantly reduced. i.e. no taking over the default gateway to do MITM, etc.

Improve this answer
4

To prevent much of this, you can Filter the number of mac addresses allowed to be registered on one switch port. Cisco calls this port-security, HP and Juniper have equivalents. By restricting the number of mac addresses that can be listed in a mac-address table (and shutting the port down in response to too many) you can stop this before it gets out of hand.

Another option (if the device is a critical component) would be to use the mac-address-table static command on a cisco switch. This would prevent the switch from registering another mac address for the device. In combination with this, you can set a static ARP entry to prevent arp poisoning (at least for your adjacent gateway) this can be deployed via GPO in Windows or in Linux via DHCP hooks. Static arp entries take precedence to dynamically received ones.

On the wireless, you can't really trust the gateway arp, the first time you're on a network, so if possible I will hard code the gateway mac-address in my arp table.

Caveats: When you're doing this sort of thing there are legitimate reasons for having a mac address that floats around. Clustered environments, VMWare guests, laptops that move. Be careful with arp and mac-address table timeouts. Setting them to low in this instance can definitely help, though it does marginally increase network traffic.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .