Welcome to this demonstration on ARP poisoning and spoofing attacks.
In this section, I will demonstrate using Ettercap,
a simple,
but effective man-in-the-middle attack allowing systems to communicate but
with all victim communications passing through the attacker.
There are several counter measures you can review in other videos,
but this one will concentrate on dynamic ARP inspection or DAI.
I will show you how to build static IP-to-MAC bindings,
as well as static ARP access control lists.
Both of these can be used as a database in dynamic ARP
inspections processes to validate IP-to-Mac bindings in ARP
traffic on untrusted ports in a network.
Then you will see what is required at a DAI static configuration.
I will also cover some of the optional features for DAI including
changing and disabling ARP rate limiting on interfaces,
as well as how to enable automatic recovery of ARP
inspection rate limit violations.
Finally,
I will show you how this DAI configuration blocks ARP
scans through its ARP packet rate limits and stops the
man-in-the-middle attacks as well.
In the following demonstrations,
the network layout consists of an Ubuntu host at 20.
1.
13 with a specially configured MAC address 00:00:20:01:01:13
based off of the IP to make it obvious.
It is connected through a Cisco 3750 switch I will use to show
you the DAI configuration to a router at 20.
1.
1 with its normal MAC address 00:23:5e:e2:5f:ee.
The attacking system is a Kali Linux with a static IP set to 20.
1.
17,
also with a special configured MAC address
00:00:20:01:01:17 to match its IP address.
ARP scan will be used to demonstrate the rate limiting
features of DAI once it's configured.
An Ettercap will be used for the man-in-the-middle attack and to
demonstrate how DAI blocks ARP spoofing attacks.
Let's start with our Kali Linux desktop.
First, I'm going to use the ARP scan tool to scan the local network.
Within the results,
we can see the default-gateway and its MAC address 00:23:5e:e2:5f:ee,
as well as our other target system at 20.
1.
13 with that specially configured MAC address.
I'll also bring up my Ubuntu system.
In the Ubuntu terminal,
I'll confirm the IP address and MAC address of this system.
It's IP address is statically set to 20.
1.
13 with the special MAC address 00:00:20:01:01:13.
Verifying my ARP cache, I can see the default-gateway at its MAC address,
as well as the Kali Linux system at 20.
1.
17 with its specially configured MAC address of 00:00:20:01:01:17.
Let's return to the Kali Linux and start the man-in-the-middle attack.
From Applications, I'll select Sniffing and Spoofing and then select Ettercap.
Within Ettercap, I'll select Sniff, Unified Sniffing on my Ethernet0,
and then I'll use the host option to scan for hosts in the network.
It'll automatically scan all 255 IP addresses and I'll add the Host
tab so that we can add some of them as targets.
My default-gateway will be selected as Target 1 and our
Ubuntu host will be selected as Target 2.
Bringing up the Targets tab, we can see that they've been appropriately added.
Starting the man-in-the-middle attack is as easy as selecting Man-in-the-middle,
ARP poisoning, and Sniff Remote connections.
I'll click OK and the man-in-the-middle attack has started.
To confirm this, I'll switch back to my Ubuntu.
Within the terminal, I'll ping 20.
1.
1, the gateway.
I'll check the ARP cache,
and now we can see the man-in-the-middle attack within the ARP cache.
Both the Kali Linux and the default-gateway appear at the same MAC address,
the Kali Linux's MAC address.
I'll also Telnet to my router and check out its ARP cache.
I'll log in, and showing its ARP cache, I can indeed see that both 20.
1.
13 and 20.
1.
17 are both at the Kali Linux's MAC address.
The man-in-the-middle ARP spoof is functioning perfectly.
Returning to the Kali Linux,
we can even see evidence of this in the Ettercap details window,
we can see the ARP poisoning of the victims is working perfectly
and it's even caught the Telnet traffic with the username and
password as I logged into my router.
If this doesn't tell you why you shouldn't use unsecured
communications over insecure networks, I don't know what will.
Alright, let's stop our man-in-the-middle attack,
close out of Ettercap, and move to my next video on ARP security through dynamic ARP inspection.