Hello, and welcome to this demonstration on how to handle ARP broadcast storms.
I will be showing how a simple single ARP scan command
using Ubuntu Linux can create an ARP broadcast storm flood
attack and cripple a network.
Wireshark and Cisco debug commands will be used to
profile the attack while it's happening.
The countermeasure you will learn is broadcast storm control.
This is a simple solution available for many manufacturers that
can be implemented on switchboards and will allow me to rate limit
traffic based on packets per second, bits per second,
or by percentage of the total bandwidth on the port.
Let's take a look at the demonstration layout.
We have a Windows 10 system and a Cisco 1800 series router
connected together with a Cisco 3750 switch.
The attack point will come from an Ubuntu Linux system
connecting through FastEthernet 9 of the switch.
Using a Linux tool called ARP scan,
the network will get flooded with malicious ARP messages.
Again,
I'll be running Wireshark on the Windows system and
debugs on the router to see the impact.
Then I will show you how to enable broadcast storm control on FastEthernet
9 to show how the rate limiting squashes the attack.
To get started,
I'm going to open a Wireshark capture on my Windows
10 system with an ARP filter.
So that you can see the effect on the router,
I'll start debugging all ARP input.
Now this is not something I do on a production router,
but here in lab,
it'll help us to see the effect of the storm and the storm control.
Now let's switch over to our Linux host.
On the Linux host,
I'll bring up a command-line terminal and we'll see
how the ARP scan command works.
ARP scan is a great tool when you're looking for IP-to-MAC address bindings,
however, as I'll show,
it can overwhelm a network and host so be careful in its use.
My favorite variation on the ARP scan command is just to
scan the local net for all the hosts.
To do that,
I add in --localnet and it's going to scan the IP range
associated with the interface card on the machine.
Quickly it comes back with a list of the IP addresses and MAC
addresses of all the systems that respond to our ARPs and I've
built a quick list of what's in my network.
Just like any tool, it can be used for good purposes or malicious ones.
To start my attack, I'm going to change the command to the one we have here.
The --bandwidth allows me to set how much bandwidth I want this scan to take up.
In this case, it's 3, 000 megs.
The next option, -S sets the source ethernet MAC address in the frame header.
The -u option sets the ARP packet header source ethernet
address to the one provided there,
and the -s sets the source IP address in the ARP packet header.
I've chosen to set these to unique values not only so that we can
see them in our debugs and in our Wireshark,
but if I'm an attacker,
I don't want it coming from my actual MAC address or my IP address.
The last option, 20.
0.
0/8 tells the ARP scan command to scan all IP addresses starting with 20.
Let's start the attack and go back to my Windows and my
router command prompt to see what's happening.
Let's bring up the router command prompt.
I'm tapping Enter and the router is totally locked up.
We can see from the debugs that it's received a series of ARP requests from 20.
1.
107 with that MAC address aabb.
ccdd.
eeff, oh man,
and my PuTTY remote session has been terminated
because the router can't even keep up.
Essentially, I've completely Denial of Service attacked my router.
Let's go over to the Windows Wireshark and see what's happening there.
Within the Windows Wireshark, we can see that ARP scan flooding the network.
This will continue until all of those 2 to the 24th
IP addresses have been scanned.
I'll stop my Wireshark and let's take a look at the information here.
Our packet detail will show us that that ARP scan came from
that MAC address I said in the command line.
The destination is everyone on the network,
and within the ARP protocol header, we see that it was a request,
again,
with that special sender MAC address that I set and
that source IP address of 20.
1.
107.
Now let's see how fast that was hammering the network.
I'm going to bring up the calculator and if we take the total number of packets,
and during this ARP scan, it looks like we got 6,
605, 400 ARPs in just a matter of 103.
76 seconds about.
Whoa!
That's 63, 660 packets per second.
Imagine what would happen if we distributed this attack over
multiple commands over multiple machines.
Now let's go over to our Cisco 3750 switch to see how we can
implement broadcast storm control as a countermeasure.
Broadcast storm control on my switch is going to be
implemented at the interfaces.
Remember that you want to implement it at your access ports,
the ones where your users are connecting to the network and anywhere
where you might be at risk of broadcast storms.
I'll move to global configuration mode to the interface
facing the attacker FastEthernet 1/0/9, and with the storm control command,
I can implement rate limiting on broadcast messages,
multicast messages, or unicast.
In this case, since ARP is primarily broadcast,
we're going to select the broadcast keyword.
Next,
I can set a level and that level can be set either in a percentage
of the bandwidth of the interface from 0 to 100% or in a bits per
second or in a packets per second.
The selection in your network is going to be up to you.
I highly recommend doing a baseline before implementing any rate limiting
to make sure you know what normal traffic looks like.
For me, bits per second and packets per second is really hard to know,
so the bandwidth based on that interface is easier to handle.
Now remember,
you need to know whether you're using fast ethernet or
gigabyte ethernet because 3% of gigabyte ethernet is
different than 3% of fast ethernet 100 MB.
In this case, I'm going to set the storm control broadcast level at 3%,
which is way higher than I need in my lab.
Now I'm going to exit out and I'll show my storm control
configuration and see what's happening with it.
Right now, it's only set on my Fa1/0/9,
the filter state is in forwarding and that's because the current level is at 0%.
My upper and lower boundaries are set at 3%,
those are individually configurable, but the default is when I set that 3%,
that's the upper level, and the lower level matches that.
Now that we've got broadcast storm control configured,
let's return to my Ubuntu Linux host and prepare for another attack.
I'll stage my attack by bringing up my command line,
but before I set it off, I'll restart my router connection to see what occurs.
So that we can see more detail on the switch interface,
I'll also turn on debugs for storm control detection.
You can see that the detection is currently running,
but the normalized rate of 0 says that there is nothing going on.
I'll return to Ubuntu Linux and start my attack.
While that attack is running,
we can see that storm control has detected an attack
and the packet filter was applied.
We can also see the normalized rate has jumped up into the three-thousandths.
Let's bring up our router prompt and see what's happening there.
Now although the router prompt shows some of this ARP attack occurring,
we can still see that it's available and serviceable.
This is because broadcast storm control,
as soon as it detected broadcasts over that 3%,
they shut down the attack.
Back on my switch prompt,
I'm going to shut off all my debugs and wait for the console messages to stop.
Now I'll show my storm control.
We can see that the broadcast storm is still happening,
but the filter state is blocking it because our current level of 37.
79% is well above our upper limit.
Broadcast storm control is stopping the attack right at the input of
that interface FastEthernet 1/0/9 and that leaves our router free and
our network free to handle normal traffic.
Let's go back to Linux and stop our attack,
return to my router prompt,
and return to my switch prompt and show my storm control.
Of course, as soon as the attack stopped,
the level of broadcast in the network stopped to below that
3% and the filter state is forwarding.
Again,
our broadcast storm control configured on our switch interface can help
us rate limit broadcast traffic within a reasonable level protecting our
network infrastructure from any form of a broadcast storm including from
an ARP broadcast flood attack.
Of course, it'll also help with loops and STP misconfigurations.
As a last reminder,
be careful on your filter rates starting above your
baselines and not implementing them on aggregated links where broadcasts will naturally be higher.