Dynamic ARP Inspection
This article is for the Security or for the routing and switching CCNA/CCNP students who wants to understand about the ARP inspection feature.
Before we start with this article, we would like to thank everybody here who support our projects
www.routexp.com ( The complete Website for "Network Engineers & Designers)
www.thenetworkdna.com
Let's talk about the Dynamic ARP inspection feature. Dynamic ARP Inspection (DAI) is a security feature that validates Address Resolution Protocol (ARP) packets in a network. DAI allows a network administrator to intercept, log, and discard ARP packets with invalid MAC address to IP address bindings.
This capability protects the network from certain "man-in-the-middle" attacks.
 |
| Fig-1.1- Dynamic ARP inspection |
ARP Cache Poisoning:
You may attack hosts, switches, and routers connected on your Layer 2 network by using "poisoning" their ARP caches. as an instance, a malicious person might intercept site visitors meant for different hosts at the subnet by using poisoning the ARP caches of structures linked to the subnet.
Consider the following configuration:
Hosts HA, HB, and HC are connected to the switch on interfaces A, B and C, all of which are on the same subnet. Their IP and MAC addresses are shown in parentheses; for example, Host HA uses IP address IA and MAC address MA. When HA needs to communicate to HB at the IP Layer, HA broadcasts an ARP request for the MAC address associated with IB. As soon as HB receives the ARP request, the ARP cache on HB is populated with an ARP binding for a host with the IP address IA and a MAC address MA; for example, IP address IA is bound to MAC address MA. When HB responds, the ARP cache on HA is populated with a binding for a host with the IP address IB and a MAC address MB.
 |
| Fig 1.2 ARP Cache Poisoning ( NB) |
Hosts HA, HB, and HC are connected to the switch on interfaces A, B and C, all of which are on the same subnet. Their IP and MAC addresses are shown in parentheses; for example, Host HA uses IP address IA and MAC address MA. When HA needs to communicate to HB at the IP Layer, HA broadcasts an ARP request for the MAC address associated with IB. As soon as HB receives the ARP request, the ARP cache on HB is populated with an ARP binding for a host with the IP address IA and a MAC address MA; for example, IP address IA is bound to MAC address MA. When HB responds, the ARP cache on HA is populated with a binding for a host with the IP address IB and a MAC address MB.
Host HC can "poison" the ARP caches of HA and HB by broadcasting forged ARP responses with bindings for a host with an IP address of IA (or IB) and a MAC address of MC. Hosts with poisoned ARP caches use the MAC address MC as the destination MAC address for traffic intended for IA or IB. This means that HC intercepts that traffic. Because HC knows the true MAC addresses associated with IA and IB, HC can forward the intercepted traffic to those hosts using the correct MAC address as the destination. HC has inserted itself into the traffic stream from HA to HB, the classic "man in the middle" attack.
Dynamic ARP Inspection
To prevent ARP poisoning assaults consisting of the only described inside the previous section, a switch should ensure that simplest legitimate ARP requests and responses are relayed. DAI prevents these assaults via intercepting all ARP requests and responses. every of these intercepted packets is tested for legitimate MAC deal with to IP deal with bindings before the nearby ARP cache is updated or the packet is forwarded to the best vacation spot. Invalid ARP packets are dropped.
DAI determines the validity of an ARP packet primarily based on legitimate MAC address to IP address bindings saved in a relied on database. This database is built at runtime with the aid of DHCP snooping, supplied that it's far enabled at the VLANs and at the switch in query. similarly, DAI can also validate ARP packets in opposition to person-configured ARP ACLs in an effort to take care of hosts that use statically configured IP addresses.
DAI can also be configured to drop ARP packets whilst the IP addresses within the packet are invalid or whilst the MAC addresses in the body of the ARP packet do not healthy the addresses certain within the Ethernet header.
DAI determines the validity of an ARP packet primarily based on legitimate MAC address to IP address bindings saved in a relied on database. This database is built at runtime with the aid of DHCP snooping, supplied that it's far enabled at the VLANs and at the switch in query. similarly, DAI can also validate ARP packets in opposition to person-configured ARP ACLs in an effort to take care of hosts that use statically configured IP addresses.
DAI can also be configured to drop ARP packets whilst the IP addresses within the packet are invalid or whilst the MAC addresses in the body of the ARP packet do not healthy the addresses certain within the Ethernet header.
Interface Trust state, Security Coverage and Network Configuration
DAI associates a trust state with each interface on the system. Packets arriving on trusted interfaces bypass all DAI validation checks, while those arriving on untrusted interfaces go through the DAI validation process. In a typical network configuration for DAI, all ports connected to host ports are configured as untrusted, while all ports connected to switches are configured as trusted. With this configuration, all ARP packets entering the network from a given switch will have passed the security check; it is unnecessary to perform a validation at any other place in the VLANs / network:
 |
| Fig 1.3 Validation of ARP Packets on a DAI-enabled VLAN |
Configuring interfaces as untrusted when they need to be trusted can result in a lack of connectivity. If we expect that both S1 and S2 run DAI on the VLAN that holds H1 and H2, and if H1 and H2 have been to gather their IP addresses from S1, then only S2 binds the IP to MAC address of H1. therefore, if the interface among S1 and S2 is untrusted, the ARP packets from H1 get dropped on S2. This circumstance would bring about a loss of connectivity between H1 and H2.
Configuring interfaces to be trusted while they're definitely untrusted leaves a safety hollow in the network. If S1 were now not walking DAI, then H1 can easily poison the ARP of S2 (and H2, if the inter- transfer link is configured as relied on). This condition can arise despite the fact that S2 is strolling DAI.
DAI guarantees that hosts (on untrusted interfaces) related to a transfer running DAI do now not poison the ARP caches of other hosts inside the community. It does now not, however, make sure that hosts from different quantities of the network do not poison the caches of the hosts linked to it.
To deal with instances wherein some switches in a VLAN run DAI and different switches do now not, the interfaces connecting such switches must be configured as untrusted. To validate the bindings of packets from non-DAI switches, but, the transfer walking DAI need to be configured with ARP ACLs. whilst it isn't feasible to determine such bindings, switches strolling DAI must be remote from non-DAI switches at Layer 3.Relative priority of Static Bindings and DHCP Snooping Entries
As noted previously, DAI populates its database of legitimate MAC address to IP address bindings via DHCP snooping. It additionally validates ARP packets against statically configured ARP ACLs. it's far crucial to note that ARP ACLs have priority over entries inside the DHCP snooping database. ARP Packets are first compared to consumer-configured ARP ACLs. If the ARP ACL denies the ARP packet, then the packet might be denied despite the fact that a valid binding exists in the database populated by means of DHCP snooping.
Stay Connected to our Projects for Network Engineers
www.routexp.com ( The complete Website for "Network Engineers & Designers)
www.networksbaseline.com
Configuring interfaces to be trusted while they're definitely untrusted leaves a safety hollow in the network. If S1 were now not walking DAI, then H1 can easily poison the ARP of S2 (and H2, if the inter- transfer link is configured as relied on). This condition can arise despite the fact that S2 is strolling DAI.
DAI guarantees that hosts (on untrusted interfaces) related to a transfer running DAI do now not poison the ARP caches of other hosts inside the community. It does now not, however, make sure that hosts from different quantities of the network do not poison the caches of the hosts linked to it.
To deal with instances wherein some switches in a VLAN run DAI and different switches do now not, the interfaces connecting such switches must be configured as untrusted. To validate the bindings of packets from non-DAI switches, but, the transfer walking DAI need to be configured with ARP ACLs. whilst it isn't feasible to determine such bindings, switches strolling DAI must be remote from non-DAI switches at Layer 3.Relative priority of Static Bindings and DHCP Snooping Entries
As noted previously, DAI populates its database of legitimate MAC address to IP address bindings via DHCP snooping. It additionally validates ARP packets against statically configured ARP ACLs. it's far crucial to note that ARP ACLs have priority over entries inside the DHCP snooping database. ARP Packets are first compared to consumer-configured ARP ACLs. If the ARP ACL denies the ARP packet, then the packet might be denied despite the fact that a valid binding exists in the database populated by means of DHCP snooping.
Stay Connected to our Projects for Network Engineers
www.routexp.com ( The complete Website for "Network Engineers & Designers)
www.networksbaseline.com
