Hello, and welcome to this video on mitigating ARP spoofing,
and man-in-the-middle attacks through DAI.
You've just seen how ARP poisoning or spoofing can
lead to a man-in-the-middle attack.
In this video, I cover a basic example of dynamic ARP inspection.
You'll see how to configure trusted and untrusted interfaces,
configure static IP-to-MAC bindings,
as well as ARP access control lists and associate them with the
DAI configuration to validate ARP traffic,
and finally, how to configure and disable ARP rate limiting on Cisco devices.
I'll bring up a switch prompt to start my DAI configuration to
block ARP scans and man-in-the-middle attacks.
My first task when preparing for a dynamic ARP inspection configuration is to
make sure that I have a valid database of IP-to-MAC bindings that the DAI
process can rely on to validate the ARP traffic.
This can be done in one of two primary ways.
For clients in your network that use DHCP,
it's most common and convenient to use DHCP snooping.
When DHCP snooping is configured on the switch,
it will rely on the DHCP snooping binding database where
dynamic ARP inspection can find the IP address,
the MAC address, the ports, and the VLANs used in its filtering process.
Alternatively, you could use static bindings.
There are two ways to do this, and in this video, I'll show you both of them.
One is to create an IP source binding of the MAC address to the VLAN to
the IP address to the interface on which it's found.
A second way you can do that is to create an ARP access control list.
Let's start with how to create static IP-to-MAC address bindings.
I'll move to global configuration mode.
To create static IP-to-MAC address bindings,
you can use the ip source binding command.
The syntax first requires the MAC address.
So I'll start with the MAC address for the machine at 20.
1.
17.
Then we need to provide the VLAN on which it's found and the IP address.
Finally,
the interface needs to be added on which that IP address
and MAC address is expected to be found,
in this case, interface f1/0/9.
Normally,
you'll create a static binding for any clients in your network that will
have a static IP address and are found on untrusted ports.
This is often one IP address and one MAC address for one port,
however, in my case since I'm using virtual machines,
I'm going to create a static binding for three systems.
I've already created it for 1 virtual machine at 20.
1.
17.
I also need to create it for the other virtual machine I have at 20.
1.
13 on the same interface.
In this case, I'll just change the MAC address and the IP address to match.
To make this work,
I do also need to add the MAC address and IP address of my
host which holds the virtual machines.
In this case, that host is at 20.
1.
55 and its MAC address is a little bit different, d481.
d7b1.
ed81.
This is one way you can create static IP-to-MAC address bindings for the
dynamic ARP inspection process so it knows what IP address and MAC address
to find on FastEthernet 1/0/9 within VLAN 1.
Another way that we can do this is through an ARP access list.
To do that,
we start with the command ARP access-list and then we
give a name for our access list, in this case,
I'm going to use all caps DAIARPLIST.
This moves us into the ARP access list configuration mode.
Here we need to permit every client with a static IP address by
referencing its IP address and its MAC address.
The command is permit ip host and then the IP address of the host,
in this case, 20.
1.
13, and then mac host and then the MAC address of that host, in this case, 0000.
2001.
0113.
Again, I need to do this for all the hosts with static configurations.
I'll add my host at 20.
1.
17 with its MAC address.
And I need to permit the computer which holds the virtual machines.
In this case, 20.
1.
55 with that MAC address d481.
d7b1.
ed81.
Lastly,
I'll exit out to complete my ARP access list and
return to global configuration mode.
The default configuration of DAI, or dynamic ARP inspection,
is that all interfaces are untrusted.
If using DHCP snooping, the same is also true.
If you enable DAI or DHCP snooping,
before you've created your trusted interfaces,
you could lose critical connectivity in your network.
So let's show you how to create your trusted interfaces for DAI.
First,
move to interface configuration mode for any
interfaces that you want to have trusted.
With DAI and DHCP snooping,
these are primarily your switch-to-switch connections and any other
trusted interface including your DHCP servers.
All other interfaces facing your clients should be untrusted.
For dynamic ARP, creating the trust is as simple as ip arp inspection trust.
At this point,
my FastEthernet 101 which faces my router and my trunks to other switches,
FastEthernet 1/0/23 and 24 are considered trusted and DAI will ignore them,
meaning it won't do the dynamic ARP inspection process
nor will it do ARP rate limiting.
Once you've created your trusted interfaces, you can turn on DAI.
Remember that DAI will automatically untrust or
distrust any of the other interfaces.
I'll exit out of interface configuration mode,
and to turn on DAI,
use the ip arp inspection command and we're going to add it for any of
the active VLANs where we want to start using DAI.
Now remember, if you're using DHCP clients and DHCP snooping,
that database has to be complete and accessible to the switch
for dynamic ARP inspection to do its job.
In this case, the IP source binding can work for static clients.
If you're electing to use the ARP access list for static clients,
you'll have to add another command, ip arp inspection.
Now you'll want to filter based on that access list.
So I'll copy the name to make sure I get it right and paste it.
Then I want to apply that filter to VLAN 1 for static filtering.
At this point,
DAI is doing its job to validate ARP traffic against the
IP-to-MAC Bindings that I've given it.
It's also rate limiting ARP traffic at 15 packets per
second on untrusted interfaces.
The basic configuration is complete,
but I want to show you a couple of optional configurations.
First, if you need to take a trusted interface and make it untrusted,
I'll show you how to do that.
I'm going to move to interface configuration mode for FastEthernet 1/0/15.
By default, this is already an untrusted interface,
but should you need to change a trusted interface to an untrusted one,
the command is no ip arp inspection trust.
Essentially, you're just reversing the trust command.
Another optional item you might want to alter is that rate limiting.
On any given interface,
we can set the rate limiting with the ip arp inspection
command but add the limit keyword.
In this case,
we can turn the rate limiting off by selecting none or we can change the rate
by using the rate keyword and setting up packets per second.
The default is 15, but you can raise or lower that.
I would only recommend changing the default based on your
needs and after a baseline has been done to detect what rate
limiting would be appropriate.
So in this case, I'll set it to the default, 15 packets per second.
I'll exit out of my configuration and now we can take a look at
what's going to happen when I ARP scan the network.
I'll bring up my Kali Linux terminal and I'll run the ARP
scan command against the local network.
Now you'll notice it got a couple of results and says it scanned 256 hosts.
But let's return to my switch command prompt.
When the ARP scan command ran,
it exceeded that 15 packet per second rate limit as shown here.
Dynamic ARP inspection caught that, and through its default behavior,
it error disabled the interface and the result was
to shut down FastEthernet 1/0/9.
At this point,
the only way to recover my FastEthernet 1/0/9 to service is to go to that
interface and issue the shutdown and no shutdown command.
Let's do that now.
Configure terminal, interface f1/0/9, I'll shut it down,
and then I'll issue the no shutdown command.
Interestingly enough,
when I brought that interface FastEthernet 1/0/9 out of its error
disabled state with the no shutdown command,
the PC host and the 2 VMs exceeded the rate limit again and dynamic ARP
inspection put it in error disable state and shut it back down.
So let's try it again.
Shutdown, no shutdown.
Now it looks like my host and my two VMs didn't exceed their rate limit.
Maybe I should have changed their rate limit to a little bit higher for this
interface due to the fact that I have three computers on it.
Another interesting output here is the DAI dropped
invalid ARP request on FastEthernet 1/0/9.
This is due to the clients performing IP address conflict checks on the network.
This is normal traffic and should be allowed.
To correct this with static clients,
I would need to add IP source bindings or access list entries for each
static client's MAC address for the source IP address of 0.
0.
This would be automatically handled for DHCP clients when using DHCP snooping.
If you need a reminder on how ARP is used to do IP address conflict checks,
go back and check out the video on this topic earlier in this course.
Alright,
now that we've seen how rate limiting error disables and shuts down ports,
let's see how we can turn on the option to automatically recover ports
so we don't have to manually correct the situation.
I'll exit the global configuration mode and the command used to
automatically recover ports due to ARP inspection rate limiting
violations is errdisable recovery cause arp inspection.
Now when a rate limit is exceeded,
the errdisable recovery cause arp-inspection command will
automatically recover the port to a functional state once the
violation condition has been removed,
meaning the ARPs have dropped below the 15-packet per second rate limit.
Now let's see how DAI handles the man-in-the-middle attack.
I'll return to my Kali Linux, bring up my sniffing and spoofing,
Ettercap attack.
I'll start my unified sniffing, open my Targets tab,
add the default-gateway at 20.
1.
1, and under Target 2, I'll add the Ubuntu host at 20.
1.
13, then I'll start my man-in-the-middle attack with ARP poisoning,
Sniffing remote connections.
Now that I've started my attack,
let's go back to the switch to see what's happening.
Within the switch interface,
we can see that dynamic ARP inspection is intercepting
and denying or dropping invalid ARPs.
These invalid ARPs are coming in on FastEthernet 1/0/9 on
VLAN 1 with a source MAC address of 0000.
2001.
0117, but associated with IP address 20.
1.
13,
this is the Kali Linux Ettercap program trying to spoof
the MAC address for the machine at 20.
1.
13 with the wrong MAC address.
These spoofed ARPs are being dropped by DAI at the ingress
of FastEthernet 9 and not able to affect any other systems
on any other switchports.
To verify this,
I will move to the router interface and check out
its ARP cache with show ip arp.
The two hosts here at 20.
1.
13 and 20.
1.
17 show their own correct MAC addresses.
Dynamic ARP inspection has identified ARP spoofing and
stopped the man-in-the-middle attack.
You have just seen how ARP scanning, ARP poisoning,
and specifically,
man-in-the-middle attacks work and are handled by dynamic ARP inspection.
Dynamic ARP inspection is another technique you can add to
your network systems to reduce or prevent risks associated
with ARP based security problems.
DAI can be a complex configuration which requires significant design
preparation including a clear understanding of how DAI will access a database
of IP-to-MAC bindings used in validating ARP traffic.
This will likely require a configuration combined
with DHCP snooping for DHCP clients,
as well as IP source bindings or ARP access lists
for clients with static addresses.
You will need to define and configure trust appropriately on
interfaces where DAI should not filter traffic and understand
the consequences for when and where untrusted interfaces are
that will inspect ARPs traffic.
And finally,
it is important to pay attention to any default and optional
configurations from your vendor related to dynamic ARP
inspection which might cause problems.
For example, with Cisco,
you may wish to tailor or even disable the DAI ARP rate limiting feature on certain interfaces based on the client and network needs.