Mitigating IP DHCP Snooping
OVERVIEW – Where Cisco’s DHCP Snooping is used to prevent a rogue DCHP server from offering up bad IPs or worse a bad gateway
My daughter’s school gives every student two different ID numbers to use. It’s so confusing for her as to which one to use when. In the same manner, allowing a second DHCP on a subnet segment is apt to confuse many host PCs and the users too. Any home router or a Windows Shared Internet or a distro of Linux can easily be setup as a DHCP server, plugged into your network and begin the confusion.
Worse, if a malicious hacker wants to intercept all packets on a network, browse them and send them on their way, setting up a rogue DHCP server, which can define the gateway IP as itself, is one way to do it (i.e., a man in the middle attack.)
Fortunately, Cisco switches allow you to mitigate either the accidental or intentional danger by defining one or more ports on a switch that can be trusted to dole out IP using DHCP. All ports in a VLAN are initially flagged as untrusted for any DHCP offers, then you may indicate which are to be trusted. We will use the global config command ip dhcp snooping to turn it on. Then we’ll use interface commands to set it up for various ports.
I learned a bit more about the somewhat mysterious background workings of DHCP. And frankly, some mysteries continue. Watching WireSharksniff packets provides a clearer idea as to what’s going on. When a client attempts to renew an IP lease (at half way thru its duration) I believe it uses a direct unicast with the original server. If never answered, it will resort to a discover broadcast, trying to locate any DHCP server to offer it an IP. What seems strange though is after a host interface is forced to close down (in Linux with an ifdown command) then brought back with an ifup, the host seems to request the same IP address it had before even if it’s requesting the IP from a different DHCP server. What’s more, if there should be two DHCP servers present (an abnormal and incorrect setup) the host seems to accept (i.e., request) the IP from the original server. This would seem to indicate the need for a hacker to disable the original DHCP server or intercept any of its offers.
Now I overcame this by temporarily disconnecting the Good DHCP server and resetting the host NIC (using ifdown + ifup). The host PC then became responsive to the Rogue server. Note in the Wireshark sniff display below that both 1.1.1.7 (Rogue) and 1.1.1.11 (Good) DHCP servers offered IPs, but in the window below showing the details of the REQUEST packet that it’s accepting the Rogue offer.
Eric Capal says it’s because the first one doesn’t have to do an ARP request since the original server is still in the host’s ARP cache.
SETUP – Where two DHCP servers are established and the fun begins
- Setup PC 11 (HD # 07) as DHCP server to dispense IPs 1.1.1.13-250/24
- Setup PC07 (HD # 01) as DHCP server (rogue) to dispense IPs 1.1.1.201-210/24
- (Oops, forgot to activate the server in Windows!)
- Activated MST instead of PVST (see previous post) in an effort to lower the BPDUs. That didn’t work as there’s only 1 VLAN in use.
- I messed around with Wireshark trying to get some capture filters to work. Need some training here. Want only source (not transmitted or destination) on one PCs MAC.
- Put both DHCP servers on one net and did some ifdown/ifup commands. Seems a host will go back to its original DHCP server and use it to get its IP. Then if that one is unavailable, it goes to the other and then becomes “loyal” to that one. Capal says that’s because the first one doesn’t have to do an ARP request since that’s still in its ARP cache.
- I was surprised to see that PC10 was leasing the 1.1.1.252 address after it was not suppose to be able to access DHCP advertisements from the rogue DHCP server. In fact it was NOT in contact with that server, it was merely re-obtaining the 252 IP from the “good” DHCP server. It was its previous IP and it was a valid IP in the “good” server’s scope of IPs. Apparently it requested the “good” server to lease that same IP even though it was originally dealt from the rogue server.
Now for the Show Run and Show IP DHCP Snooping commands:
2950sw1#sho ip dhcp snooping ?
binding DHCP snooping bindings
| Output modifiers
<cr>
2950sw1#sho ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
1-1024
Insertion of option 82 is enabled
Interface Trusted Rate limit (pps)
———————— ——- —————-
FastEthernet0/24 yes 3
The show interface command on the “snooping” port doesn’t seem to show anything about snooping.
2950sw1#sho int fa 0/24
FastEthernet0/24 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0011.bbd0.4358 (bia 0011.bbd0.4358)
MTU 1500 bytes, BW 100000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s
input flow-control is unsupported output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of “show interface” counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
430 packets input, 78061 bytes, 0 no buffer
Received 261 broadcasts (0 multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 4 multicast, 0 pause input
0 input packets with dribble condition detected
4791 packets output, 552239 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
2950sw1#sho run
Building configuration…
Current configuration : 2166 bytes
!
version 12.1
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname 2950sw1
!
!
ip subnet-zero
!
ip dhcp snooping vlan 1 1024
ip dhcp snooping
ip domain-name IT5199
!
!
spanning-tree mode mst
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
!
spanning-tree mst configuration
name region1
revision 1
instance 1 vlan 1-1024
!
!
!
!
!
interface FastEthernet0/1
switchport access vlan 50
switchport mode access
spanning-tree portfast
!
interface FastEthernet0/2
switchport access vlan 50
switchport mode access
spanning-tree portfast
!
interface FastEthernet0/3
spanning-tree portfast
!
interface FastEthernet0/4
spanning-tree portfast
!
interface FastEthernet0/5
spanning-tree portfast
!
interface FastEthernet0/6
spanning-tree portfast
!
interface FastEthernet0/7
spanning-tree portfast
!
interface FastEthernet0/8
spanning-tree portfast
!
interface FastEthernet0/9
spanning-tree portfast
!
interface FastEthernet0/10
spanning-tree portfast
!
interface FastEthernet0/11
spanning-tree portfast
!
interface FastEthernet0/12
switchport mode trunk
!
interface FastEthernet0/13
switchport mode trunk
!
interface FastEthernet0/14
spanning-tree portfast
!
interface FastEthernet0/15
spanning-tree portfast
!
interface FastEthernet0/16
spanning-tree portfast
!
interface FastEthernet0/17
spanning-tree portfast
!
interface FastEthernet0/18
spanning-tree portfast
!
interface FastEthernet0/19
spanning-tree portfast
!
interface FastEthernet0/20
spanning-tree portfast
!
interface FastEthernet0/21
spanning-tree portfast
!
interface FastEthernet0/22
spanning-tree portfast
!
interface FastEthernet0/23
spanning-tree portfast
!
interface FastEthernet0/24
spanning-tree portfast
ip dhcp snooping limit rate 3
ip dhcp snooping trust
!
interface GigabitEthernet0/1
!
interface GigabitEthernet0/2
!
interface Vlan1
no ip address
no ip route-cache
shutdown
!
ip http server
!
line con 0
logging synchronous
line vty 0 4
login
line vty 5 15
login
!
!
!
monitor session 1 source interface Fa0/21 – 24 rx
monitor session 1 destination interface Fa0/3
end
