In this section, we'll be dealing with ARP broadcast storms.
We'll cover the three common ways that they can occur including
hardware problems such as loops in the network,
software misconfigurations, and hacker Denial of Service attacks.
I'll cover some common mitigations including broadcast storm control,
intrusion detection prevention systems, and network-based authentication.
In this video,
I will be concentrating most heavily on broadcast storm control as some of
these solutions in more detail in other videos in this module.
ARP is an unauthenticated, insecure, and primarily broadcast protocol.
As a broadcast,
it uses an ethernet Mac destination of all Fs or all ones in binary
designed to reach all stations on a network or in a VLAN.
Broadcast protocols like this are stopped by a router or
other Layer-3 devices in the network.
ARP broadcasts are used to communicate messages to either
unknown receivers or when the receiver is meant to be every
station in the local area network.
For these reasons,
all devices need to receive the ARPs into their
buffers and process them to some degree.
Thankfully, just like life, broadcast communication is generally limited,
and therefore, only a small percentage of normal traffic.
Too much broadcast traffic, ARP or otherwise,
causes a broadcast storm which negatively impacts the
performance of the LAN and its systems.
When the impact is so large that network or other
LAN resources become unavailable, it is a Denial of Service.
Denial of Service, or DoS, occur due to various network misconfigurations,
as well as for malicious sources.
When it happens,
it can overwhelm a network by consuming bandwidth or overwhelming
network router and switch processors and packet buffers.
It'll likewise affect end systems and shared services like servers
by forcing their processors and memory buffers to handle the ARP
traffic over other communications.
Systems handle these issues in various ways,
some are more stable and can weather the storm while
others can become unstable and crash.
There are three main causes for broadcast storms to occur,
firstly, hardware issues, in particular,
malfunctioning network cards or physical loops created in the
network can allow a broadcast to propagate unchecked.
Although underpinned by a hardware loop,
broadcast storms can also be created by software malfunctions or
misconfigurations of the Spanning Tree Protocol,
or STP, whose main job is loop avoidance within redundant topologies.
Finally,
malicious attacks can be created through malware or live hacking which
can create the same Denial of Service conditions by saturating the
network resources with ARP broadcast traffic.
Switches use protocol intelligence, in particular,
associating switchports with MAC addresses to filter and direct traffic.
When A and D communicate,
the switch uses their MAC addresses to forward their frames.
Hubs are multiport signal regenerating repeaters.
They have no protocol intelligence.
Instead,
they take all incoming signals and flood them out all other active ports,
regardless of addressing.
Due to scalability and security issues along with lack of
programmability and protocol awareness,
hubs are no longer desirable to have in any network.
They do still, however, exist in the wild.
So let's take a look at how a hub can make a hardware broadcast storm occur.
The broadcast storm problem happens when a hub is doubly connected
into the network and a physical loop is created.
When a broadcast enters this network,
it will be flooded by both the switch and the hub.
The hub's lack of intelligence and lack of loop avoidance
mechanism means it will continue to flood broadcasts.
Many switches have programming that help protect networks from this
particular problem by detecting the loop and breaking it.
Unfortunately,
the loop avoidance mechanisms may not be fast enough to
prevent some host and network issues, or in worse situations,
they could be disabled or not at all present leading to a crashed network.
Today's fully switched networks are designed to allow for
automatic recovery through redundant paths,
and at the same time, stop loops through the spanning tree protocol,
or STP.
However, if STP is disabled or improperly configured,
the same loop situation and broadcast storm could
occur as in the previous scenario.
If there is malicious intent,
ARP broadcast storms for malware infecting systems or attacks can
easily create Denial of Service conditions.
The attack consists simply of generating enough ARP broadcast traffic to
disrupt the normal use of the network and its systems.
A Distributed Denial of Service attack, or DDoS,
occurs when an attacker infects one or more legitimate
systems with remote controlled malware without the system
owner's knowledge or permission.
These bots are then used to coordinate and distribute an attack.
Often the attacker does not directly participate in the DDoS and as
systems are usually unknowingly infected and trusted,
the attack is more effective on the network.
There are several techniques I will cover in this module
which are part of a layer defense.
You will need to evaluate each one to see which seem the most
applicable to your environments and risks.
For broadcast storms of any kind,
one of the most common techniques is to rate limit
traffic based on the communication type.
Depending on your switch manufacturer's feature set,
this could include rate limiting broadcasts,
or multicasts, or even unicasts.
In this case,
rate limiting broadcasts would most affect ARP
storms and denial of service attacks.
Depending on the network gear,
you may also be able to rate limit the ARP protocol specifically.
Rate limiting broadcasts or ARPs can be done based on bandwidth
measurements or potentially by packets or bits per second.
On the Cisco switches I will use in the demonstration,
broadcasts can be limited on any of those.
ARPs specific rate limiting is part of dynamic ARP inspection,
not as a standalone feature.
Since I will cover dynamic ARP inspection in a later tutorial on
ARP spoofing and man-in-the-middle attacks,
you should check out those videos to learn more.
Some general rate limiting best practices include
first knowing normal traffic patterns, particularly,
understanding broadcasts in ARP traffic through baselining is important.
Without a baseline as a starting point, you will not know where to begin.
Second,
rate limiting is most effective and necessary at the edge where
untrusted user devices access the network.
Aggregated links between your switches and routers at
your core and distribution layers,
as well as to trusted systems is usually an
unnecessary location to do rate limiting.
Regardless of where you do it, there is a danger limiting legitimate traffic.
It is possible to miss normal traffic conditions in a
baseline which should not get blocked, but if they work,
could result in a denial of service on your own network.
Lastly,
determine what features are available and what action
should be taken when exceeding a rate limit.
These could include disabling ports, filtering traffic,
or sending alarms in SNMP traps, for example.
Intrusion detection or prevention systems in the network can play a
very large role in identifying many types of issues.
Depending on the feature set,
IDS and IPS can provide data that goes into the network baseline and
help prepare for upgrades and prevention planning.
They also collect data to localize the source and
cause of issues when they occur.
Some can be made reactive to problems.
This means they can potentially help localize issues by shutting
down switchports if certain conditions are met like a broadcast
storm or an attack signature is found.
IDS and IPS can also aggregate your logging and alarms,
which is invaluable when deconstructing problems
later or during a forensic analysis.
Although IDS and IPS systems go well beyond the scope of
the problems presented in this module,
it is important to note that depending on features,
they can certainly help with broadcast storms and are,
of course, applicable to all the ARP related attacks in this module.
In this section,
you have seen how ARP and other broadcast storm Denial of Service
conditions can occur due to malfunctioning hardware,
hub in switch network loops, or malicious attacks.
Some solutions include rate limiting traffic through broadcast storm control or
potentially ARP specific rate limiting which help prevent ARP and other
broadcast storms from crashing a network and its systems.
ARP and broadcast storm detection can be done using IDS,
IPS,
or other ARP detection software which helps by alerting
administrators and cataloging particulars of the problem.
Lastly,
validating traffic users and devices in a network is
an excellent way to limit attacks.
These topics will be specifically addressed in later videos of this module on ARP spoofing.