How to prevent arp poisoning attacks?

  • 0
  • 2
  • Question
  • Updated 10 months ago
  • Answered
Hello,

I was just curious about this following gtac article: https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-prevent-ARP-Poisoning  

It seems, my understanding that exos will log mac addresses to IP addresses based upon the DHCP packets traversing the switches.  But how would this work for static assigned devices, where they do not query for DHCP?  Obviously a DHCP packet does not traverse to that mac address, therefore the switch would be unaware of it and potentially drop the traffic?

I appreciate the assistance.
Photo of kjstech

kjstech

  • 624 Points 500 badge 2x thumb

Posted 10 months ago

  • 0
  • 2
Photo of Patrick Voss

Patrick Voss, Alum

  • 11,594 Points 10k badge 2x thumb
You can add DHCP bindings in manually using:

"configure ip-security dhcp-bindings add"
Photo of kjstech

kjstech

  • 624 Points 500 badge 2x thumb
Ok Extreme x690's are at my core, layer 3 and any dhcp request from any of our access switches will aggregate to this core, which has uplinks to our servers where DHCP resides.

So to prevent arp poisoning / arp spoofing attacks, would it be best to apply this at the core, or at the edge?  We have all Cisco 3750's at our edge terminating the end users/phones (dhcp), printers (static) and other misc devices (static).
Photo of Karthik Mohandoss

Karthik Mohandoss, Employee

  • 6,058 Points 5k badge 2x thumb
Hi,

If the core switch is the only exit point for inter vlan communication then enabling ARP validation in core should be sufficient. 
Photo of kjstech

kjstech

  • 624 Points 500 badge 2x thumb
The more I think about it, yes that would protect arp poisoning between vlans, which may be enough to protect from eavesdropping a client in VLAN3 for example to a domain controller or server in VLAN1, since that traffic comes back to the core.

But then I think what about an malicious actor attacking the same subnet, like a neighboring PC for example.  I think I will start at the edge and work my way back to the core a VLAN at a time.  We just have to manually program in statics like printers and scanners.  I know in the Cisco switch to do so you specify the IP, MAC and switchport like this:

ip source binding 0024.9B17.XXXX vlan 7 10.7.2.228 interface Fa1/0/1

And in my testing on one of our lighter used access switches in our end rack, on the uplink portchannel to the Extreme x690's we just added:
ip arp inspection trust
ip dhcp snooping trust.

That port channel is 2 ports in an mlag to each x690 stack.  The servers are off the core stacks in mlags, so those two commands appear to allow the DHCP traffic between the access and the core.

I am in the process of getting the latest kali linux to do some demonstration and verification of the fix.

So to recap, once I make my way back to the core, for any statically assigned devices (which is almost everything, I can use the command configure ip-security dhcp-bindings add  which seems to be the equivalent to Cisco's ip source binding.

Then the uplinks to our vm cluster and dell blade chassis need to be all trusted, since there are DHCP servers in there and a mash up of VM's both static or DHCP assigned.  I'm guessing the port to the internet would be trusted as well because there is traffic from a million different sources to and from the world.

Edit:
The more I think about it, I think the priority is to protect the edge access switches.  Nothing in the core is patched into anywhere that a malicious actor would have access to.  It's not like they can easily get into the data room without triggering alarms, to plug into the core and have enough time to arp spoof and gather NTLM hashes long enough to finally find one that is easily cracked (our vendor only found 1, and it was not a domain admin).
(Edited)