No matter how much I google I can't get a definitive answer.

  • Static ARP entries:

    Static ARP addresses prevent only simple attacks and do not scale on a large network, since the mapping has to be set for each pair of machines resulting in n^2-n ARP entries that have to be configured when n machines are present: On every machine there must be an ARP entry for every other machine on the network, which are n-1 ARP entries on each of the n machines. While static entries provide some security against spoofing if the operating system handles them correctly, they result in maintenance efforts as address mappings of all systems in the network have to be distributed.

  • ARP detection software:

    This method is pretty useless. There are very few ARP detection programs out there, and the few that do exist are either free junk or over priced. In addition, to use these programs on a windows machine requires installing special drivers for your wireless cards. Recommendation: Don’t use. http://lewiscomputerhowto.blogspot.com/2014/03/perform-man-in-middle-attack-with-kali.html

So if neither anti-ARP software nor Static ARP entries work then how do you protect against ARP spoofing in a big network?

  • You would have to handle it in the switches. For strict client only networks you only allow access to the upstream port/router. This config is also good for WLAN. Otherwise you block re-announcements of ARP (which does restrict mobility). Ultimatively however ARP is broken and if you care younwould need to use Port based (NAP) security (802.1x)
    – eckes
    Jun 4, 2017 at 16:46

4 Answers 4


First of all: Except for the availability and stability of the connections, ARP spoofing is only a problem when the layers above don't implement effective measures to ensure integrity and confidentiality of the data. Since ARP spoofing is not the only way to execute a MiTM attack, you should focus on the security of the layers above first to ensure that the data cannot be tampered. (IPsec, TLS etc.)

Further it's a good practice to keep LAN segments as small as possible since the overhead of several protocols can impact the overall performance and stability. It also allows you to reduce the attack surface by isolating hosts into subnets and VLANs so that they are only available to hosts which are required to use the offered services.

Once you are done with segmentation you could re-evaluate whether static ARP tables are feasible for some of your segments. Then you could also have a look at 802.1x-2010 aka MACsec.

Anyway, prepare yourself to setup an own CA. ;)

  • Hi sorry for late reply. Does 802.1x protect against ARP spoofing? Meaning are ARP messages encrypted with secret keys and all that?
    – Leftover
    Jun 7, 2017 at 18:46

Not a direct answer to your question but I'd try to address the largest risk first. i.e., not look for a n^2-n solution - rather, just for the routers and gateways.

IMHO, spoofing individual end-points is far less valuable to any attacker than the gateways/routers. That would also reduce the burden of tracking endpoints that move around the LAN; and would not require integration to DHCP servers just to compensate.

It would also change the detection problem. You'd just have to look for the one node that everybody's talking to, that's not one of your gateways. Should be a simpler one to spot in any traffic visualization. Detection of m:n spoofing from just traffic visualization is a lot harder (cue: one more application for next ML enthusiast!).

  • This would only protect connections that go through the router would it not? If the whole LAN uses switches, both level 2 and 3, then how do you protect from ARP spoofing? Cause switches, both level 2 and 3, don't have ARP tables (level 3 does but they're only used for switch maintenance, not to give mac addresses to endpoints).
    – Leftover
    Jun 4, 2017 at 15:02
  • Yes. More accurately, it would help track any node trying to impersonate the router/gateway. Protecting (as in preventing the connection from succeeding) on a LAN is a lot harder.
    – Sas3
    Jun 4, 2017 at 15:04
  • So there really isn't any way?
    – Leftover
    Jun 4, 2017 at 15:13
  • There might be. I don't know of any. :( If I had to solve this problem (i.e., if it's high priority), I'd try a DIY solution (e.g., snort + some python code that would disable the switch port to which the offending node is connected).
    – Sas3
    Jun 4, 2017 at 15:29

Some switches (typically the high end models) support the 'private VLAN' concept. This allows hosts only to communicate with a defined uplink port. This eliminates the problem caused by ARP spoofing, since a host spoofing ARP entries would only possibly disrupt its own connectivity.


When using bind you can automatically add static arp entries on the server. This resulted in some problems on about 10% of the clients, that did not correctly release...

on commit { set ClientIP = binary-to-ascii(10, 8, ".", leased-address); set ClientMac = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));

execute("/usr/sbin/arp","-s",ClientIP,ClientMac); }

on release { set ClientIP = binary-to-ascii(10, 8, ".", leased-address); set ClientMac = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));

execute("/usr/sbin/arp","-d",ClientIP); }

on expiry { set ClientIP = binary-to-ascii(10, 8, ".", leased-address); set ClientMac = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));

execute("/usr/sbin/arp","-d",ClientIP); }

You must log in to answer this question.

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