I’m just going to re-use the Topology we had going from the Dynamic ARP Inspection, as IP Source Guard uses DHCP Snooping as well as the mechanism that allows it to work, though Static Bindings can be configured (Which is why Host B now has a Static IP).
IP Source Guard nor VLAN Hopping are really robust topics, so I’ll run through IP Source Guard first, then on the bottom half of this post cover VLAN Hopping and Switch Spoofing!
What is IP Source Guard?
Similar to Dynamic ARP, this is a way of configuring interfaces to be mapped to particular IP Addresses, either Dynamically or by a doing a Static Binding – Which is why DHCP Snooping is required to reference its DHCP Snoop Bind table for interface info!
By default you “enable” it at interface level and the switch maps that IP Address to that interface # (along with the MAC if using port-security), and if either of those values change, the traffic will be dropped coming into that interface.
IP Source Guard configuration
I’ve left Host A on DHCP to show how it Dynamically enables IP Source Guard, and Host B is Statically Assigned its IP Address to demonstrate Static Binding.
Host A configuration:
SW1(config)#int fa1/0/1
SW1(config-if)#
SW1(config-if)#ip verify ?
source source address
SW1(config-if)#ip verify source ?
port-security port security = Also matches Source MAC Address (more secure)
smartlog Smartlog denied packets = Dropped packets collected by Netflow Collector
tracking tracking ip device = No idea, means that the interface is tracked?
<cr>
SW1(config-if)#ip verify source
So all we need is “ip verify source” on the interface and we are golden, however we can add “port-security” to also match the DHCP Bind table MAC Address for the interface, or “Smartlog” to send dropped packets to a Netflow collector to log.
Enabling Source Guard and opening the Port to grab a DHCP Address on Int Fa1/0/1:
SW1(config-if)#ip verify source
SW1(config-if)#no shut
SW1(config-if)#
*Mar 1 00:30:52.271: %LINK-3-UPDOWN: Interface FastEthernet1/0/1, changed state to up
*Mar 1 00:30:53.278: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to up
SW1(config-if)#
No console messages or anything letting you know the IP Source Guard is hard at work!
Verification that IP Source Guard is working:
SW1#sh ip verify source
Interface Filter-type Filter-mode IP-address Mac-address Vlan Log
——— ———– ———– ————— —————– —- —
Fa1/0/1 ip active 10.0.10.101 10 disabled
SW1#
This output shows:
- The Interface being binded
- What traffic is filtered (ip = all)
- Filter mode = Active (on)
- IP Address = Mapped IP
- MAC Address = Empty (no port-security feature enabled)
- VLAN #
- Log = Disabled (the smartlog option left off)
All the information we could ever possibly want for IP Source Guard!
Enabling / no shut IP Source Guard for Host B:
SW1(config)#int fa1/0/2
SW1(config-if)#ip verify source
SW1(config-if)#no shut
SW1(config-if)#
Not much to it, lets see how its changed the “sh ip source verify” table:
SW1#sh ip verify source
Interface Filter-type Filter-mode IP-address Mac-address Vlan Log
——— ———– ———– ————— —————– —- —
Fa1/0/1 ip active 10.0.10.101 10 disabled
Fa1/0/2 ip active deny-all 10
SW1#
Because this is a Statically Assigned IP Address, it shows the deny-all until we create a Static Binding for it, which we will do in Global Config:
Configuring a Static Binding for IP Source Guard:
SW1(config)#ip source ?
binding static IP binding
SW1(config)#ip source binding ?
H.H.H binding MAC address
You will need that devices MAC Address to setup a Static Binding, so where best to get it then using “sh cdp nei det” to obtain it!
Using “sh cdp nei” to obtain info needed:
SW1#sh cdp nei
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
S – Switch, H – Host, I – IGMP, r – Repeater, P – Phone,
D – Remote, C – CVTA, M – Two-port Mac Relay
Device ID Local Intrfce Holdtme Capability Platform Port ID
SW2 Fas 1/0/6 122 S I WS-C3750V Fas 1/0/6
SW2 Gig 1/0/2 178 S I WS-C3750V Gig 1/0/2
SW2 Gig 1/0/1 178 S I WS-C3750V Gig 1/0/1
HostA Fas 1/0/1 147 R S I 1841 Fas 0/1
HostB Fas 1/0/2 171 R S I 2801 Fas 0/1
I happen to know this device IP Address is 10.0.10.102, however if tasked on exam day, “sh cdp nei detail” will provide the IP Address of the device as well – Then a lookup in the MAC Tables dynamic entries will show its MAC Address!
Looking up info in the MAC Table for the Static Binding:
SW1#sh mac address-table dyn
Mac Address Table
——————————————-
Vlan Mac Address Type Ports
—- ———– ——– —–
10 001b.5336.f2cd DYNAMIC Fa1/0/2
10 001e.f797.f14b DYNAMIC Fa1/0/1
1 5897.1eab.c801 DYNAMIC Gi1/0/1
1 5897.1eab.c802 DYNAMIC Gi1/0/2
1 5897.1eab.c808 DYNAMIC Fa1/0/6
Total Mac Addresses for this criterion: 5
SW1#
With a LOT more devices, you may need to use “sh cdp nei detail” to get IP Address info / device platform info, but this is more than enough for our static binding.
That being said, back to Static Binding IP Source Guard:
SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#ip source ?
binding static IP binding
SW1(config)#ip source binding ?
H.H.H binding MAC address
SW1(config)#ip source binding 001b.5336.f2cd ?
vlan binding VLAN
SW1(config)#ip source binding 001b.5336.f2cd vlan ?
<1-4094> binding VLAN number
SW1(config)#ip source binding 001b.5336.f2cd vlan 10 ?
A.B.C.D binding IP address
SW1(config)#ip source binding 001b.5336.f2cd vlan 10 10.0.10.102 ?
interface binding interface
SW1(config)#ip source binding 001b.5336.f2cd vlan 10 10.0.10.102 int ?
Async Async interface
Auto-Template Auto-Template interface
BVI Bridge-Group Virtual Interface
CTunnel CTunnel interface
Dialer Dialer interface
FastEthernet FastEthernet IEEE 802.3
(… lots more interface types)
SW1(config)#ip source binding 001b.5336.f2cd vlan 10 10.0.10.102 int fa1/0/2 ?
<cr>
SW1(config)#ip source binding 001b.5336.f2cd vlan 10 10.0.10.102 int fa1/0/2
SW1(config)#
Try saying that command three times fast!
That should be it for configuring a Static Binding for our Host B with a Static Assigned IP, lets take a look at how the “sh ip verify source” table is viewing it:
SW1#sh ip verify source
Interface Filter-type Filter-mode IP-address Mac-address Vlan Log
——— ———– ———– ————— —————– —- —
Fa1/0/1 ip active 10.0.10.101 10 disabled
Fa1/0/2 ip active 10.0.10.102 10 disabled
SW1#
So it treats it the same, except of course it was statically set rather than dynamically learned, but that is all about all there is to IP Source Guard, it just keeps a table / mapping of IP / MAC information to interfaces and drops traffic that doesn’t match those values.
Now onto the topic of VLAN Hopping, and how we can prevent it on our networks!
By the nature of this type of attack some things have to go incredibly right for the attacker as we’ll see, however this is used in conjunction with an Access-Port sending traffic over a Dot1Q Trunk port with two separate VLAN IDs: One for the Native VLAN (to get it onto the Trunk) and the VLAN # it is attacking (to be tagged on its way off the Trunk) – aka Double Tagging!
However unfortunately for the attacker, they must plug into an Access Port within the Native VLAN, and we must be running non-ISL Trunks for this to work, because this requires that VLAN Tagging concept Dot1Q provides us!
So how the attach unfolds if he does get that Access Port within the Native VLAN:
- The device sends a frame with two VLAN ID Tags, Native in front, target VLAN second
- The frame hits the trunk interface, the trunk sees the Native VLAN tag and removes it, and send the traffic over the Trunk
- The frame still contains the VLAN ID Tag # of the Target VLAN, so when it arrives on the other side of the Trunk, it appears as though the remote side Tagged it for that VLAN
- The frame is then allowed onto that VLAN from the Trunk interface
Now the attacker is able to flood traffic onto this VLAN to slow it down, propagate malicious traffic in general, bad news!
So how do we mitigate it?
By changing the Native VLAN so that no Hosts are in it!
The first part of this attack was to plug into Access-Port that is part of the Native VLAN, but if no ports are in the Native VLAN, we have just avoided this type of attack entirely!
This will result in a bit of extra overhead because now all frames will need to be tagged without the Native VLAN in use, but worth it for the extra layer of Security.
You could also Prune the Native VLAN from Trunk interfaces, but Option A just seems easier / better / less prone to accidents to allow VLAN Hoppers in!
Switch Spoofing – Back from the CCNA Grave to haunt your network!
This is an oldy but goody security issue, that by default, all switchports will form a Trunk if the opposing side of the link is actively attempting to form a Trunk.
I think it used to be that all ports were in an Actively Trunking mode, but now they are just in “Auto” mode, which will allow a Trunk formation if the other side initiates it!
The classic fix – Make all Non-Trunk interfaces Access Ports or better yet, Disable them unless they are meant to be Trunking!
I am sure you already knew that, I don’t care when you took your CCNA (if its still certified), you were probably taught this at some point – So keep your switchports secure!
That is it for SWITCH Security Features for now (I think), onto CDP / LLDP
I think that about does it for Security for right now, going to take another break here to review CDP in detail along with its IEEE industry standard friend LLDP – See you there!
The DEVNET GRIND! 