- protects from rouge servers
- protects from misused clients that floods dhcp-requests
- ensure critical systems are not effected by lack of dhcp-offers
- provides higher availlability% and uptime against DHCP DoS attacks
The movers unpacked her items ,and decided to help out even farther, by plugging things up for the exec. In one box, she had one of these;
Okay I know everybody has seem a linksys or similar soho wireless device, right ?
About 99% of the rogue dhcp-servers are something like the above, & mistakenly installed into a network by an unknowing staff or end-user.
Will this device was configured with a typical 192.168.1.0/24 address mask , and was setup as a dhcp-server. It was mistakenly connected to the corporate wide network. In doing so; "it become the dhcp-server for the internal LAN, & causing all sorts of havoc, until the device was located and removed"
Depending on the client machine and how fast the dhcp-server responds, you might get the real corp-dhcp-servers, or you might received the rogue-dhcp-server offer from a linksys. Since the internal lan was not configured to use the 192.168.1.0/24 address space, clients who received a lease within that dhcp-scope where blackholed or deny of services, due to the lack of an valid routeable address.
So cisco starting many years ago, realize that we need to protect the LAN from it's self and it's users. Since rogue dhcp servers was popping up more and more, the dhcp snooping feature soon became the standard protection within the enterprise arena for DHCP-servers outages.
For cisco it's an straight forward configuration.
1st we must identify our trusted ports that contains our DHCP-server(s). Yes you establish trusted ports for these servers, because by default ; all ports are untrusted when you enable dhcp-snooping.
here's my trusted port ( gi 0/2 )
DHCP snooping trust/rate is configured on the following Interfaces:
Interface Trusted Allow option Rate limit (pps)
----------------------- ------- ------------ ----------------
GigabitEthernet0/2 yes yes unlimited
Custom circuit-ids:
!
interface GigabitEthernet0/2
ip dhcp snooping trust
end
Next we enable dhcp snooping globally, and also specify the vlan(s) that will be enabled for dhcp-snooping;
config t
ip dhcp snooping vlan 1
ip dhcp snooping
no ip dhcp snooping information option
I also disable the information-option feature, since we don't need this in this case and nor does this dhcp-server support that feature
Next, we configured dhcp rate-limits ( otional) . Cisco recommends no more than 100pps for a regular access switchport, and trunks that carries multiple vlans, needs a much higher rate set.
config t
int range gi 0/3-48
description "my local lan access ports for desktops"
ip dhcp snooping limit rate 100
I'm going to use dhcp-binding and with an off switch hosted file on a tftp-server. Ideally we would want to used something more secured like scp, but tftp-server was my easiest solution to deploy.
ip dhcp snooping database tftp://172.16.1.3/file
ip dhcp snooping database write-delay 20
I 've also configured a write-delay value, which is useful in heavy dhcp environments that has a host of hosts using dhcp.
Now let's see what happens;
A client make a request, if the port is untrusted the information is looked at and logged to our dhcp snooping binding file. If a port is enabled as a untrusted port and the dhcp message was that of a server, it would be dropped, hence protecting the network from unrecognized dhcp-servers.
Interface Trusted Allow option Rate limit (pps)
----------------------- ------- ------------ ----------------
GigabitEthernet0/3 no no 100
Custom circuit-ids:
Any ports that exceed the rate-limit , would also have it's messages dropped. It would go into an err-disable state.
The following show cmds helps provide information on the dhcp-stats and other useful information;
show ip dhcp snoop statistics
show ip dhcp snoop statistics
Packets Forwarded = 78
Packets Dropped = 0
Packets Dropped From untrusted ports = 0
custA#
show ip dhcp snoop binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
AA:AA:AA:BB:BB:CC 172.16.1.6 84531 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:FF:FF 172.16.1.11 84935 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:BB:FF 172.16.1.8 84717 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:BB:BB 172.16.1.5 84408 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:CC:DD 172.16.1.9 84778 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:BB:EE 172.16.1.7 84622 dhcp-snooping 1 GigabitEthernet0/4
AA:AA:AA:BB:CC:FF 172.16.1.10 84873 dhcp-snooping 1 GigabitEthernet0/4
00:0C:29:52:0F:4F 172.16.1.4 84697 dhcp-snooping 1 GigabitEthernet0/3
Total number of bindings: 8
show ip dhcp snoop database
Agent URL : tftp://172.16.1.3/file
Write delay Timer : 20 seconds
Abort Timer : 300 seconds
Agent Running : No
Delay Timer Expiry : Not Running
Abort Timer Expiry : Not Running
Last Succeded Time : 02:02:25 UTC Sat Jan 19 2013
Last Failed Time : 01:55:05 UTC Sat Jan 19 2013
Last Failed Reason : Expected more data on read.
Total Attempts : 11 Startup Failures : 3
Successful Transfers : 7 Failed Transfers : 4
Successful Reads : 0 Failed Reads : 1
Successful Writes : 7 Failed Writes : 0
Media Failures : 0
A few thing that you must taken into consideration; if you want to deploy dhcp-snooping and using the binding database;
- cisco requires ntp
- and syncronize clock, with the correct time
This is due to the dhcp-lease information has time/date values enclosed in the offer. Without a correct clock, the binding details could be exploit and flawed.
so enable some sort of NTP to a clock source;
custA#sh run | i ntp
ntp clock-period 36028843
ntp server 172.16.1.1
And ensure your system-clock is 100% correct;
show clock
02:30:25.459 UTC Sat Jan 18 2013
The binding file at the URL location is basic and simple and holds the entries learned during the dhcp snooping process
e.g
TYPE DHCP-SNOOPING
VERSION 1
BEGIN
172.16.1.6 1 aaaa.aabb.bbcc 50FB4E88 Gi0/4 336c813d
172.16.1.11 1 aaaa.aabb.ffff 50FB501C Gi0/4 b01dbbad
172.16.1.8 1 aaaa.aabb.bbff 50FB4F42 Gi0/4 08a88f63
172.16.1.5 1 aaaa.aabb.bbbb 50FB4E0D Gi0/4 fdc5a686
172.16.1.9 1 aaaa.aabb.ccdd 50FB4F7F Gi0/4 037b959f
172.16.1.7 1 aaaa.aabb.bbee 50FB4EE3 Gi0/4 d93819a7
172.16.1.10 1 aaaa.aabb.ccff 50FB4FDF Gi0/4 d8de358e
172.16.1.4 1 000c.2952.0f4f 50FB4F2E Gi0/3 0d5de493
It reccommended to store this file off the switch and on some sort of external device.
Here's a typical DHCP request or correct term discover from a client;
Client-Ethernet-Address aa:bb:cc:cc:dd:dd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Parameter-Request Option 55, length 9:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
Option 119, LDAP, Option 252, Netbios-Name-Server
Netbios-Node
MSZ Option 57, length 2: 1500
Client-ID Option 61, length 7: ether aa:bb:cc:cc:dd:dd
Lease-Time Option 51, length 4: 7776000
Hostname Option 12, length 12: "C02H61ZJDV7M"
END Option 255, length 0
PAD Option 0, length 0, occurs 12
here's a a typical DHCP offer from a dhcp-server;
172.16.1.1.67 > 172.16.1.13.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x8cf45faa, Flags [none] (0x0000)
Your-IP 172.16.1.13
Client-Ethernet-Address aa:bb:cc:cc:dd:dd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 172.16.1.1
Lease-Time Option 51, length 4: 86400
RN Option 58, length 4: 43200
RB Option 59, length 4: 75600
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 172.16.1.1
Domain-Name Option 15, length 3: "hackersaregoood.com"
Domain-Name-Server Option 6, length 4: 8.8.8.8
END Option 255, length 0
PAD Option 0, length 0, occurs 9
here's a client acking the request;
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from aa:bb:cc:cc:dd:dd, length 300, xid 0x8cf45faa, secs 1, Flags [none] (0x0000)
Client-Ethernet-Address aa:bb:cc:cc:dd:dd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Parameter-Request Option 55, length 9:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
Option 119, LDAP, Option 252, Netbios-Name-Server
Netbios-Node
MSZ Option 57, length 2: 1500
Client-ID Option 61, length 7: ether aa:bb:cc:cc:dd:dd
Requested-IP Option 50, length 4: 172.16.1.13
Server-ID Option 54, length 4: 172.16.1.1
Hostname Option 12, length 12: "C02H61ZJDV7M"
END Option 255, length 0
PAD Option 0, length 0, occurs 6
here's a the final response message known as the lease or DHCP lease from a dhcp-server;
172.16.1.1.67 > 172.16.1.13.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x8cf45faa, Flags [none] (0x0000)
Your-IP 172.16.1.13
Client-Ethernet-Address aa:bb:cc:cc:dd:dd
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 172.16.1.1
Lease-Time Option 51, length 4: 86400
RN Option 58, length 4: 43200
RB Option 59, length 4: 75600
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 172.16.1.1
Domain-Name Option 15, length 3: "hackersaregoood.com"
Domain-Name-Server Option 6, length 4: 8.8.8.8
END Option 255, length 0
PAD Option 0, length 0, occurs 9
Things to take away from this all;
- DHCP snooping is helpfull
- most newer model switches support this feature
- It's support on most L2/L3 switches
- Proctects your network
- Does not protect from hijack ip_address
- Does not protect static assigned hosts
I hope you found this post helpful. Keep your network healthy ,by filtering and protecting unwanted dhcp messages.
Ken Felix
Freelance Network/Security Engineer
kfelix at hyperfeed dot com
No comments:
Post a Comment