Unauthorized DHCP offers

[LCMember4427]

Hi,

We have a PA500 box running 4.1.11 software.

I our school's dorms area students sometimes succeeds in connecting private routers' LAN side to the local LAN infrastructure, hence clients start getting sporadic DHCP lease offers from such routers which leads nowhere.

How can I set up an alarm to trigger on detected DHCP lease offers from other devices than our own list of 'legal' DHCP servers?

Thanks for help on this

regards Tor

[_slv_]

Hi

I'd suggest you to think about DHCP snooping on access switches. You can simple disable ability of putting DHCP servers into your LAN.

[ericgearhart]

I wonder if building an ACL to block UDP port 67/68 traffic could help with this problem too

[_slv_]

it wouldnt help because dhcp traffic doesnt pass throught PAN. Such problem should be "cuted" on access switches.

[ericgearhart]

I meant build the ACL on the switches themselves

But yes, I see what you mean... looking at Cisco's docs, DHCP snooping would be the "cleanest" way to solve the problem, if your switches support it

http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_1/nx-os/security/configuration/guide/sec_dh...

[craymond]

If you are using the PAN for your L3, as in,  it is the gateway for all of your vlans, or you have a virtual wire between your user switches and your L3 GW, you should be able to block dhcp to everything except for your dhcp servers by using an allow rule from each gateway ip and dhcp server ip using dhcp, and a deny rule for all user subnets from port 67 (or just the deny rule above an any-any rule that you use between user zones and servers). Granted they could use a different port, but that should fix it most of the time. Otherwise you will have to use dhcp snooping, as stated above by others, which should be available on most high end switches or use a rogue checker - though that isn't real time.

[cmateam]

Some rogue detection tools can communicate with switch ports and shut those off, assuming switches can understand such instructions.  There are tools like Aruba Airwave (I think Dell uses the same product, just branded differently) that supports such things.  A NAC type system would be the next thing, but could be difficult to employee in a school setting I'd imagine. @egearhart recommends something similar, but requires you to have cisco equipment it looks like.

[mikand]

What one usually does to make sure that DHCP-clients doesnt put in rogue DHCP-servers or for that matter steal each others ip-addresses is to separate the clients from each other along with countermeasures regarding DHCP in the access-layer.

That is:

1) Setup private vlan (or protected vlan) on the edge ports. This way traffic between two clients will be forced through your control nodes (that is either a router or a PA-device depending on your taste). Dont forget to also do the same for the uplinks (otherwise clients in the same building cant reach other clients but it will be able to reach clients in the other building (that is one switch per building or such)).

2) Enable DHCP-snooping along with DHCP-relay. This way any DHCP request(s) from an edgeport will be forced (as unicast) to your designated DHCP-server (this ip can of course be anycasted for redundancy in larger networks).

3) Dynamic ACL. The above (DHCP-snooping) often include a feature where the access-switch will keep track of the DHCP response and put that ip as allowed srcip for the particular edgeport. This gives that if the client tries to spoof an ip-address the access-layer will drop these packets.

4) Option82. When DHCP-snooping (or if it was DHCP-relay, I dont remeber) is being used you can enable Option82 which means that the access-switch will add its own name along with which interface the DHCP-request showed up at in the DHCP-request which is redirected to your designated DHCP-server. This information can then be logged in your DHCP-server which gives that you will see not only the mac-address and which IP the client was using but also where in your network this client was physically connected.

That is client sends a DHCP-request. Access-switch use DCHP-snooping to intercept this request and by the configuration of DHCP-relay send this request as a unicast towards designated DHCP-server along with Option82 information (switchname + interface the request came from). The DHCP-server responds and the access-switch will use the assigned ip (for the client) as an ACL on the edgeport the client is connected to. This will efficiently stop any address-spoofing attempts. As a bonus you will now in your DHCP-server (if it supports Option82) have a log of IP + mac but also where the client was physically connected to your network.

[ericgearhart]

This is a great answer... I completely forgot about taking advantage of private VLANs to "funnel" the traffic to a control point.