Cincinnerdi Tech Stuff

A mind-numbing read if ever there was one

Mitigating IP DHCP Snooping

leave a comment »

OVERVIEW – Where Cisco’s DHCP Snooping is used to prevent a rogue DCHP server from offering up bad IPs or worse a bad gateway

Lab 03312007

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.

Wireshark DHCP

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

Advertisements

Written by scottledyard

2007, March 31st at 8:44 pm

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: