In this section, we will examine how ARP poisoning,
ARP spoofing,
and man-in-the-middle attacks work and methods for dealing with them.
Before we do that,
I want to remind us how normal unicast traffic is used with the ARP
cache to send communications between systems.
When our system at IP 1 with MAC A wants to send
data to the router at IP 2 MAC B,
they're going to use the entries in their ARP cache.
This works because the router knows the computer at IP 1 has MAC A
based on its ARP cache and the computer knows that the router at IP 2
must be at MAC B based on its ARP cache.
As you all know, this is the whole purpose of the ARP cache,
to keep this IP to MAC address binding straight and allow
us to forward our traffic appropriately.
Knowing that ARP is not a secure protocol and the ARP
cache is the primary reference for where to send data
gives hackers a great deal of power.
A primary attack is called ARP poisoning.
In this attack,
the goal is to use ARP packets to force updates to the ARP caches of
targeted network systems to change their understanding of the MAC
address associated with a particular IP address.
One common version of ARP poisoning is spoofing the default-gateway.
This is done by convincing clients in the network that the IP address of
the default-gateway is at the attacker's MAC address.
This is done by continually sending ARP packets,
usually gratuitous ARPs,
at the targets so that ARP caches do not get the chance to be corrected.
Likewise, the target can just as easily be the default-gateway itself.
Updating the gateway's ARP cache entry for our client victims IP with
the attackers Mac would cause the gateway to send all packets destined
for the victim to the attacker instead.
As long as this ARP poisoning continues,
the victims would use their poisoned ARP caches and
forward their data to the attacker.
This attack can be carried out on one victim,
two victims as shown here, or on an entire network of devices.
Once established, the attacker has access to all data the victims are sending.
This destroys all confidentiality of any data not encrypted in the network.
If the attacker does not elect to forward the data
and only receive it as shown here, the attack becomes a blackhole.
Clients in the gateway can send all they like,
but the data never reaches its intended destination.
As we've seen before, port security allows us to restrict access to the network.
It is a port-based MAC address authentication of
systems connecting to the network.
Each port security enabled interface in a network has a list of one
or more MAC addresses associated with that port.
The port security MAC addresses can either be dynamically
learned on the interface or statically programmed.
The default maximum allowed MAC addresses by most vendors is just one,
but that's configurable.
Since they can be dynamically learned, they can also be dynamically timed out.
This in combination with a maximum number of MAC addresses is
the way I demonstrated how to stop switch MAC address table
flooding earlier in this module.
When a client is attached,
it starts sending data packets with a source Mac in the packet.
If the source MAC matches the port security configuration,
then traffic is allowed to pass.
If the attached MAC address is not in the port security
configuration or exceeds the maximum allowed MAC addresses,
a violation occurs.
The action the switch takes is configurable and usually
defaults to shutting off the port.
Optionally,
the action can be to restrict traffic and may allow SNMP
traps and violations counters to be logged.
Also, if a violation occurs,
the port may be configured to either require manual
intervention to reenable or may automatically reenable once
the violation condition has been corrected.
Some implementation considerations,
port security works well where the network infrastructure is fairly stable,
especially the user access layer.
If your environment changes radically and you're concerned about security,
port security can be difficult to manage.
Better security techniques might include strong network isolation of distrusted
systems and identity management for access to the network.
It is important to plan processes related to equipment
lifecycle from integration to the network,
policies on where port security is to be implemented,
how it's to be handled in moves, changes,
ads, and finally, decommissioning of equipment in the network.
Make sure there is a clearly defined and supported process for port recovery,
when it's appropriate for ports to auto recover,
how long it will take, or should a manual administrative process be required.
Port security has some challenges including the
administrative overhead in creating and maintaining the
process for equipment in this environment.
As well, it requires not only processes,
but training of both IT staff and users.
Users can get frustrated with port security when
they do not understand the reasons, the processes,
or how to deal with the violations.
Lastly, port security can be circumvented with spoofed MAC addresses,
therefore, it should only be one part of a security design to identify,
isolate, and restrict untrusted devices in users in the network.
Another very powerful network access control comes in 802.
1x authentication.
This port-based authentication model allows for better and
broader security than simple port security.
In this model, there are three main actors,
the client detaching to the network called the supplicant,
the switch called the authenticator,
which as you will see is not the one doing authentication,
and the authentication server which holds the authority to
authenticate both users and devices to the network.
How it works is a client attaches to the wired or wireless network.
In a wireless scenario, the switch is simply an access point.
The switch is configured for 802.
1x authentication on its port and only allows communication about
authentication via EAP called Extensible Authentication Protocol frame.
These EAP frames are all that is allowed until authentication passes and
the port can be transitioned to allow user data to pass.
Once the switch knows the client is acceptably 802.
1x capable,
it becomes a pass-through device passing the actual
authentication between the client and the server.
The actual authentication used is determined by the capabilities
and configurations of the client and the server.
This could be based in hardware like MAC addresses,
can use things like usernames and passwords,
or could even include things like certificates.
Regardless of the model of authentication,
the process generally results in one of two outcomes,
the authentication succeeds and the switchport is allowed to transition
to an authorized state and traffic can pass or the authentication does
not succeed and the switchport remains unauthorized and the user does
not have access to the network.
Some considerations,
this model centralizes the authentication making it easier to scale.
It also removes a switch from authentication limiting some types of attacks.
As I said before,
there are quite a variety of supported authentication models
which include tunneling and authorization,
as well as accounting features which significantly enhances network security.
This model not only works wired and port based,
but increases the already strained wireless security models currently available.
It supports bidirectional authentication not only of the client to the server,
but the server to the client.
This along with the strong ability to support user
authentication as part of AAA raises the difficultly on
spoofing and man-in-the-middle attacks.
802.
1x integrates well with wired and wireless VLAN assignments and policies to
aid in segregating devices and traffic once authenticated.
One of the challenges, however, is that not all systems are 802.
1x compliant and variations in vendor implementations
sometimes make setup difficult to say the least.
Our last major form of mitigation against ARP based attacks is very
specific to ARP and is called dynamic ARP inspection,
or DAI.
DAI works by intercepting and inspecting any inbound ARP requests or
replies on what DAI denotes as untrusted interfaces.
By default, DAI assumes all interfaces as untrusted,
So part of the configuration is specifically allowing trusted interfaces.
These would include connections to other DAI switches
and other trusted infrastructure.
It is very important to understand and configure these trust states as
untrusted interfaces could block necessary connectivity.
When ARP traffic is intercepted on an interface,
the source IP and Mac addresses are validated against a trusted database
source which holds IP to MAC bindings for that interface.
That trusted source can be statically programmed or dynamically learned.
Static sources include statically programmed IP-to-MAC bindings
for a switchport or an access control list,
or ACL.
I will be demonstrating this in the video on dynamic ARP inspection.
More common in business environments is to use a DHCP snooping binding database,
which is built dynamically as clients attach to the network and go through the
normal DHCP process to automatically obtain an IP address.
As the DHCP process occurs,
DHCP snooping acts as a firewall between untrusted DHCP
clients and any trusted DCHP servers.
With respect to dynamic ARP inspection,
DHCP snooping's role is not just a valid DHCP traffic,
but to store and maintain the DHCP snooping binding database
which holds the switchport information, the VLAN ID,
and the assigned IP-to-MAC binding for untrusted clients in the network.
As I said,
that database is used also to verify ARP packet IP-to-MAC address
bindings through the dynamic ARP inspection process.
Regardless of how or where the database is built,
DAI uses it to filter any ARP traffic with invalid bindings.
Another default feature of the DAI on Cisco switches is that ARP
traffic is automatically rate limited to a maximum of 15 packets
per second on any untrusted interfaces.
Along with ARP validation checks,
this helps to stop many ARP scan and ARP spoofing threats.
Some implementation considerations.
DAI does require some trusted source to validate ARP
traffic or it will be dropped.
This is important so switches perform DAI always have
access to an accurate and trusted database source for
validation and inspection functions.
Good design will not store the database locally the switches,
but centrally on an accessible file server in the network.
It is important to properly understand design and configure trust on
interfaces leading to other DAI switches and trusted network
infrastructure as they should not be filtered.
If a source should be trusted and is not,
a major loss of connectivity could occur.
Although, in small environments like my lab,
static bindings and ARP ACLs work as a validation source they're not scalable.
In most implementations,
DAI will rely on DHCP snooping and its process for creating
and maintaining in the binding database.
Therefore,
a thorough understanding of how that process works and how
switches access the database is critical.
DCHP snooping is used for DHCP clients and is
configured along with DAI per VLAN,
which makes it important to group users and devices appropriately into
access VLANs where DHCP snooping and DAI are configured.
Lastly,
pay attention to default configurations which might impact normal
and approved connectivity and traffic flows.
For example,
default rate limiting on Cisco's interfaces forces an error
disable condition which disables ports forcing administrator
manual intervention to reenable.
Depending on your policy around ARP and rate limits,
it may be useful to change the default rate or set the error disable
condition option to automatically recover the port once the ARP rate is
below the limit and the violation has been removed.
As an example of how DAI works and what will happen in the video demonstration,
let's assume that our attacker gained access to the network,
passed our network authentication,
and has either gotten his or her machine a valid IP address or
commandeered a valid machine on the network at IP 3 MAC C.
As long as DAI is configured on all entrusted ports in the VLAN,
our packets will be rate limited and validated against
an IP-to-MAC binding for that port.
Trusted ports are neither filtered nor rate limited.
If our attacker starts an IP or ARP scan in the network,
unless tailored very slowly,
it will trip up the ARP rate limiting on the interface.
As previously noted,
Cisco defaults this to 15 packets per second with a violation
default to error disable and shut down the port.
If an auto recovery mechanism is in place,
the interface will recover once the scan stops.
Otherwise,
it will require intervention through a shutdown and no shutdown to recover.
Let's assume that our hacker is very stealthy and has taken their time
to scan very slowly so as not to trip any alarms,
broadcast storm control, IDS, nor ARP rate limiting features.
The attacker is ready to start a man-in-the-middle attack.
This is done by sending ARP packets with spoofed IP to MAC
bindings through victims to poison their ARP caches forcing
them to misdirect their packets.
But wait, dynamic ARP inspection to the rescue.
As soon as ARP packets enter the DAI configured interface and do not
match the valid IP to Mac bindings associated there,
DAI drops the traffic and the man-in-the-middle attack is stopped before the
traffic can enter the switch or affect the target ARP caches.
As an overview,
ARP is an insecure protocol and can be used to
attack the network and its systems.
You have seen how these issues and attacks,
including DoS, ARP poisoning, or spoofing,
and man-in-the-middle attacks occur.
As with all security, a layered approach is necessary.
In this section,
the common countermeasures and mitigations include authenticating users,
devices, and traffic to the network.
Port security is a great way to do network-based
authentication based on the MAC address of the devices.
It is simple and effective, but has some limitations based on the MAC addresses,
administrator overhead, and the ability to be tricked or MAC spoofing.
802.
1x is a more complex and flexible model to authenticate
users and devices to the network.
It centralizes authentication and provides a variety of solutions
based on the client and server capabilities.
The primary limitation here is supporting clients without 802.
1x capabilities or limited authentication options.
Finally,
DAI is an ARP specific way to filter ARP traffic on VLANs by validating
it against IP to MAC bindings in a trusted database.
It also offers rate limiting of ARP specific traffic.
It does require extra design and implementation considerations to support the database primarily through DHCP snooping.