The Lab Exercise
Many cybersecurity attacks use established protocols like DHCP and ARP to find a way to learn information and cause problems in a network. Two switch features, DHCP Snooping and Dynamic ARP Inspection (DAI), prevent attacks based on DHCP and ARP, respectively. Both use a similar configuration model to enable the feature in a VLAN and then either trust or not trust each switch port.
DAI relies on a list of valid IP/MAC address pairs. The list includes IP/MAC address pairs considered to be legitimate in the subnet. DAI then monitors incoming ARP messages on untrusted ports, comparing the ARP messages to the table of legitimate address pairs and filtering the messages that do not conform to the entries in the table.
DAI uses a table built by DHCP Snooping or by ARP ACLs. For this lab, configure DHCP Snooping correctly, which causes DHCP Snooping to create a table called the DHCP Snooping Binding Table. This table lists the IP/MAC address pairs for any host that successfully leased an IP address. Then also configure DAI so that it uses the DHCP Snooping Binding table to make its decisions.
For this lab, take these specific steps.
- Configure DHCP Snooping as follows:
- Enable DHCP Snooping in VLAN 10.
- Switch SW1 operates as a layer 2 switch, not a layer 3 switch, so disable the insertion of DHCP Option 82 headers.
- Configure (or use the default) so each switch port is either trusted or untrusted for DHCP Snooping.
- Configure DAI as follows:
- Enable DAI in VLAN 10.
- Analyze the devices attached to the switch and ask yourself: Which devices will have entries in the DHCP Snooping Binding table? Then, make a note of those devices and switch ports.
- Configure (or use the default) so each switch port is either trusted or untrusted for DAI Snooping.
Initial Configurations
The initial configuration on switch SW1 places all four of its ports into the same VLAN (VLAN 10). In addition, the router has an IP address configured on its LAN interface (G0/0) so that it can ping the DHCP server’s address on the LAN. The router should also be able to ping the client PCs once they lease an IP address.
|
|
hostname SW1 ! vlan 10 ! interface range FastEthernet0/1-3 switchport access vlan 10 switchport mode access spanning-tree portfast ! interface GigabitEthernet0/1 switchport access vlan 10 switchport mode access spanning-tree portfast |
Example 1: SW1 Config
|
|
hostname R1 ! interface GigabitEthernet0/0 ip address 172.16.10.1 255.255.255.0 no shutdown ! interface GigabitEthernet0/2/0 ip address 172.16.12.1 255.255.255.0 no shutdown ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0 |
Example 2: R1 Config
The PCs each act as a DHCP client, expecting to lease an IP address and learn the mask and default gateway settings from the DHCP server. You can assume the DHCP Server shown in the figure works. However, to be complete, Example 5 shows the IOS DHCP server configuration that you could use to support this lab. (The CPT and CML files supplied with this lab use this same configuration.)
|
|
hostname DHCP_Server ! ip dhcp excluded-address 172.16.10.1 172.16.10.100 ! ip dhcp pool subnet1 network 172.16.10.0 255.255.255.0 dns-server 172.16.10.9 default-router 172.16.10.1 domain-name example.com ! interface GigabitEthernet0/0 ip address 172.16.10.9 255.255.255.0 no shutdown ! router ospf 1 network 0.0.0.0 255.255.255.255 area 0 |
Example 3: DHCP Server (IOS Router)
Hello i think that SW1 config answer in line 3 should be:
no ip dhcp snooping information option
Henri,
You are correct! Fixed now. Thanks much,
Wendell
Hello,
Since we are talking about security I have two questions:
1) Some operating systems allow us to change the mac address, and if I well understood, DAI can detect that as explained in the Cert Guide Vol. 2 pg 159-160.
That means if we modify the host’s mac address, the mac address in the ethernet header or arp header (I don’t know which one will be changed) won’t match the hardware mac address and DAI will discard the frame.
Is what I am telling true or not?
2)If the answer of the question 1 is true:
If the DAI is not enable, all “switchport port-security” functionalities become deciduous for hackers.Because an attacker could use an allowed mac address to bypass the security rules.
True or not?
Thanks in advance.
Hi Edmund,
Taking your questions by number:
1: I haven’t tested that specific scenario. Let’s say in that scenario the user is legit. If they change the MAC and reboot, causing the switch port to go down, I believe then DHCP Snooping will remove its snooping binding table entry, when the PC comes up and DHCP leases the switch makes a new DHCP snooping binding entry. So DAI has a legit entry to use.
DAI is more about an attacker on a second port when stable on the first port, which isn’t the scenario you described. But taking your scenario literally, if changing the MAC on the PC left the switch port up, without testing it, I would guess DAI would stop the traffic sent by the PC with the new MAC address. HAven’t tested it, though.
2) I’d say no to that one. First, the attacker is unlikely to know your port security config. But if they did, the sequence would be to get access to a port in an office or cubicle. Then somehow discern which switch port it’s attached to. Only then could it take advantage of knowing the port security config (which is again unlikely). But yes, knowing the switch config, and connecting to a wall plate, knowing the switch port, you could connect with port security allowing the connection.
Then… not discussed in CCNA are other security measures. I’d suggest checking out 802.1X/EAP, which would then require authentication before the user could send any traffic past the switch. Or Software Defined Access (SDA), with the DNA Center Controller and ISE, which also requires authentication before the user can use the LAN and also dynamically assigns the user to a VLAN based on their login credentials.
Good questions, made me think!
By re-reading my questions, I noticed I did not explain very well the scenario, sorry…
Here is a more consistent scenario :
(legit user) Allowed PC1 with mac address AAAA:BBBB:0001 connected to a switch (F0/1) with
port-security activated for only this mac: AAAA:BBBB:0001
(hacker) Not allowed LAPTOP with mac address CAFE:CCCC:9999
If the hacker know the PC1’s mac address, he could :
1)Replace his own mac address (LAPTOP) with PC1’s mac address
In example with the following command in linux : “ifconfig ethX hw ether AAAA:BBBB:0001”
Now the hacker’s laptop has the mac address AAAA:BBBB:0001 and the switch cannot make the difference between PC1 and the LAPTOP because the only way to do that is by looking at the mac address.
2)The hacker sitting at the desk with the PC1 on it, UNPLUG the PC1’s RJ-45 connector and PUT it directly in his laptop.
It does not matter if the maximum allowed port is 1, because the allowed pc has been unplugged
and there is still only one device connected on the port (The LAPTOP with the allowed m/c).
The hacker don’t need to know the switch’s port-security configuration, because he is already
allowed to connect using the PC1’s mac address.
I have an option on my modem-router that allows to restrict the Internet access by filtering mac addresses. So I tested the scenario;
I change my PC’s mac address, ping my router and finally analyzed what’s happen with wireshark:
The src mac address has been change in the frame sent (ethernet II layer 2) and (ARP layer 3) , I was able to bypass my router’s security.
To come to the conclusion,I just wanted to know if a cisco switch port-security option is able to detect this trivial attack because maybe it looks directly at the real hardware mac address and if it’s not the case, can ARP Inspection tools or something else help to avoid this problem?
I know the question is out the scope of CCNA, but if we are sure that port-security could be easily bypassed, we have to be aware of that.
P.S. Concerning SDA – DNA, I just finished the book and I never listen about that so far, I think it’s a very interesting concept that make a lot of what we learn old-fashioned.
Thank you for your availability.
Hi Edmund,
Thanks, much clearer now.
On your #1, the attacker learns the MAC of the legitimate PC via some other means than knowing the switch config. Got it. So the short answer is yes, port security cannot help in that case. If the attacker uses that same MAC address and that same Ethernet port it appears to be the same device to port security. port security checks only the source MAC address of incoming frames.
To me, that means the attacker has access to the PC. There’s a whole other world of tools to protect access to the OS, to prevent someone with access to the OS from connecting to the network to use it, and so on. But Port Security isn’t the solution here.
I don’t think DHCP Snooping or DAI help in this case, either. Your starting point is an attacker on the same port as a legit PC using the same MAC as the legit PC. So they have physical access to the space and keyboard access to the OS so they can look around and learn things. So I still think your approach to the problem (ignoring CCNA scope) is about protecting access to the legit PC.
Hope this helps,
Wendell
PS SDA is cool. So is SD-WAN, ACI, all the software-defined options from Cisco. But you have to know the CCNA stuff to understand the more advanced things. EG, with SDA, there’s a underlay campus that, when installed by DNA-C, functions as a routed access layer. That alone requires half of what you learn in CCNA! Kudos to you for digging in and learning well.
Thanks for the answer, now it’s clear for me, port-security is a useful functionality but we have to pay attention for the case we mention earlier.
I used the word “hacker” for a general purpose, but sometime users can create security holes unintentionally, for example, a young employee that want to play games on Internet or something else using his own laptop because usually companies don’t allow users to install programs on the company’s pc or the pc is not enough powerful to make the job, etc …
Most of cases analyzed in the book are scenarios around a switch, meaning that the hacker is located inside the company.So we can’t exclude the fact, with a very low probability, that the hacker could be a big rat working for the company knowing his allowed mac address, but as you say : “There’s a whole other world of tools”.
I think we talk about security enough and I better focus on the CCNA exam, thanks for the blog, I really appreciate it and the books too.
Thank you Wendell, you are our superstar!
You’re quite welcome, Edmond!
Hi Mr. Odom,
Referencing OCG Vol 2, page 161, Example 8-5.
On DAI, you wrote, “If you were to configure a switch only with commands shown in Example 8-5, the switch would filter all ARPs entering all untrusted ports in VLAN 11.”
The commands in Example 8-5 are as follows:
#ip arp inspection vlan 11
#interface GigabitEthernet1/0/2
#ip arp inspection trust
So, my question (my thought) is that without DHCP snooping and ARP ACLs, and when only the commands (stated above) are used, what would the switch compare the filtered ARPs to?
Azza
Hi Azza,
Thanks for the note.
I had to go back and read to get the context. And I see what’s probably confusing there.
So, what I mean is this:
Configure like Example 8-5 only, with no ARP ACL and no DHCP Snooping, and DAI filters all incoming ARPs on untrusted ports. The reason: There’s no table with which to find permissible entries, as you suggest in your question. So, DAI alone creates deny-all-ARP logic for untrusted ports.
Then, that sentence you quoted was meant to be a lead-in to suggest that you must also configure ARP ACLs or DHCP snooping, and here’s how to also config DHCP snooping in the scenario in the book, as per Example 8-6.
Hope this helps! Feel free to follow up.
Wendell
Hi Mr. Odom,
Referencing OCG Vol 1, page 566, Line 15.
You write, “The show ipv6 route command lists the link-local address of the neighboring router, rather than the global unicast or unique local unicast address.”
I tested the ‘show ipv6 route’ command in all it variations and it does not list the link-local address of the neighboring router.
However, my lab is in packet tracer and that might have something to do about it.
I have checked the errata file on the OCG Vol 1 “CCNA-200-301-Vol1-Errata-2023-02-01” and I could not find anything about this.
So, is the statement still correct that the ‘show ipv6 route’ command lists the link-local address of the neighboring router?
The following are the examples from my lab:
Router(config)#int g0/0/0
Router(config-if)#ipv6 add 2001:db8:1111:2::1/64
Router(config-if)#do sho ipv6 int bri
GigabitEthernet0/0/0 [up/up]
FE80::260:5CFF:FEB6:501
2001:DB8:1111:2::1
GigabitEthernet0/0/1 [administratively down/down]
unassigned
Router(config-if)#do sho ipv6 route
IPv6 Routing Table – 3 entries
! Legend omitted for brevity
C 2001:DB8:1111:2::/64 [0/0]
via GigabitEthernet0/0/0, directly connected
L 2001:DB8:1111:2::1/128 [0/0]
via GigabitEthernet0/0/0, receive
L FF00::/8 [0/0]
via Null0, receive
Router(config-if)#do sho ipv6 nei
IPv6 Address Age Link-layer Addr State Interface
2001:DB8:1111:2::2 7 00D0.BCA4.5A01 REACH Gig0/0/0
Router#sho ipv6 rou summar
IPv6 routing table name is default(0) global scope – 3 entries
IPv6 routing table default maximum-paths is 16
Route Source Networks Overhead Memory (bytes)
connected 1 88 124
local 2 176 248
Total 3 264 372
Number of prefixes:
/8: 1, /64: 1, /128: 1
Hi Azza,
Welcome to the site. I appreciate the Mr. Odom, but feel free to call me by my first name.
I think you’re missing some context, but FYI, the book is correct as is, and I think Packet Tracer works correctly as well on this point.
As for your question, I refer you back to the page, to the entire paragraph just above Figure 24-8 from which the sentence you quoted comes from. Couple of key facts from that:
– It mentions the next-hop address will be a link-local address (LLA).
– It mentions the show ipv6 route command.
– The one show ipv6 route command you listed in your post does not list a route that has a next-hop address field in it.
What routes have a next-hop address? Those that require the local router to forward packets to the neighboring router. For example, if your Packet Tracer topology had two routers in it (like the topology in Figure 24-8), and you enabled OSPFv3, R1 would learn a route for “Subnet 2” per the figure. that route would list R2’s LLA as the next hop address.
EG, add this to the routers:
ipv6 router ospf 1
router-id 1.1.1.1 (or 2.2.2.2, or 3.3.3.3, make them unique)
on each interface, add:
ipv6 ospf 1 area 0
Assuming you had already enabled IPv6 unicast routing, and had already configured correct global unicast addresses on the interfaces, then that additional configuration should make OSPF work. Then the routes learned by OSPF (which have a next-hop address value) will list the LLA of the neighboring router.
Hope this helps,
Wendell
Hello Wendell,
Thank you so much for your efforts in making this lab.
I just wanted to point out that the lab and the picture for it is slightly off. The lab has additional devices.
Thank you
You’re quite welcome, John. Thanks for the heads up.
Hi Wendell,
A quick doubt. If we use fixed IPs in our LAN devices instead of DHCP, we cannot use DAI feature, right? (Because DAI depends on DHCP snooping binding table).
Vicente,
DAI can can also use something called an ARP ACL, which provides matching logic for ARP messages independent of the DHCP process.
Hi Wendell – this is a general question. I’m getting stuck on the logic of DAI trust vs. not trusted settings on ports. Specifically, why do we want all non-DHCP clients to be trusted for DAI?
Hey Bill,
DAI is tricky. And discussing DAI while keeping it basic is challenging, too. So, to do that, the chapter discusses DAI with the DHCP Snooping Binding Table, but with only a bare mention of ARP ACLs. In short – and this is the key – for an untrusted port, the only way DAI approves of an ARP is if that host successfully used DHCP. With no DHCP Snooping table entry, no passing the DAI check. So any port connected to devices with static IP addresses, or to anything not a DHCP client, you need to trust.
In real life, this can be reasonably applied in most cases, particularly if the site follows a consistent plan for which ports connect to user devices and which don’t, rather than arbitrary choices for switch ports.
Hope this helps.
Wendell