logging rogue dhcp servers with dhcp snooping

[lunitin]

Hello,

Using the comware based, 5130 switch, is there a way to log (to loghost) when a rogue dhcp server is dropped by dhcp snooping? I can't seem to get any log messages when this occurs. With the following, my upstream dhcp works with all of the Gig ports and any rogue dhcp servers plugged into the Gig ports do not function, however there are no log messages associated with the dropping of packets from a rogue dhcp server.

Boot image version: 7.1.045, Release 3113P03
Compiled Apr 28 2016 16:00:00
System image: flash:/5130ei-cmw710-system-r3113p03.bin
System image version: 7.1.045, Release 3113P03
Compiled Apr 28 2016 16:00:00

----

dhcp snooping enable
dhcp snooping log enable
#
Interface Bridge-Aggregation1
 dhcp snooping trust
#
interface GigabitEthernet1/0/x
 dhcp snooping binding record
#
info-center loghost x.x.x.x

----

 Thanks 

[Ian Vaughan]

Howdy,

Hmmm - I'm thinking that sounds like a bug.. If logging is enabled but nothing shows in the logs something is fishy. I take it all of the other syslog traffic sucessfuly finds its way onto the log aggregation host?

What about if you debug the dhcp snooping function? Does that seem to work as expected, just the logging missing?

Are you also planning to implement Ip source guard as the dynamic filter that uses the DHCP snooping information table?

something like -

 ip verify source ip-address mac-address

on the port configuration? That way only hosts who have sucessfully negotiated with the legitimate trusted DHCP server get access through those ports. It is applied on a port by port basis so you should be able to pilot it.

Is the 5130 acting as the IP helper / DHCP relay in this confguration?

The examples are around the page 390 mark in the 5130ei "Security Configuration Gude" - Follow the White rabbit down the "technical support / manuals" link off the product page -> Manuals tab -> "Setup and Install - General"

If DHCP snooping doesn't alert to syslog it should be capable of raising an SNMP trap. Are you monitoring SNMP from these switches? There are a wide range and variety of SNMP monitoring tools available starting with basic free ones. We can have that conversation later :-)

To be honest I'm seeing more interest these days in applying dot1x at the edge and tie-ing it back into say Windows NPS as the RADIUS server or even Aruba Clearpass if you have Wireless in play also. That way you standardise all of your user facing ports to a common configuration and solve all of the above issues as if you don't have the credentials you don't get past the port. Furthermore all of your "moves and changes" operations of swapping VLANs around when devices & people move aren't needed anymore as you pick up the VLAN dynamically when you login.

As the authentication is done on a session by session basis (by MAC) even a rogue DHCP server as a VM on a PC bridged through the NIC won't get in without the credentials to get past the dot1x port security.

Might be worth a look - I thought it was worth mentioning.

HTH - let us know how you get on. Please use the "Kudos" and "Solved" buttons to let others know if and when we are helpful in answering your question.

Kind regards

Ian

[lunitin]

Hi Ian,

Other log entries are successfully making it to the log host.

The 5130 is not acting as an IP helper or DHCP relay.

> What about if you debug the dhcp snooping function? Does that seem to work as expected, just the logging missing?

I changed the log level to debugging to no avail:

 info-center source default loghost level debugging

[parnassus]

Nothing changes if you, via CLI, try an undo then an enable of the DHCP Snooping Logging feature [*]?

As example (in system-view mode):

undo dhcp snooping log enable

dhcp snooping log enable

Is the IPv6 DHCP Snooping Logging feature enabled or disabled (default)?

Look for a relationship between IPv6 and IPv4 DHCP Snooping Logging features...and force an undo ipv6 dhcp snooping log enable to disable the feature for IPv6 (default), if you then enable it does the IPv4 DHCP Snooping Logging starts to work as expected or not?

[*] if it is a bug...it's quite interesting to note that that feature was introduced with Release 3109P03 (May 2015)...so many months ago...and no bugs were reported regarding DHCP logging or DHCP Snooping Logging not working...so far.

Have you tried to update the Switch to release 3113P05 (just to see if anything changes)?

[Ian Vaughan]

Hello,

I hacked together a freebie broadband router as a "rogue" and did a mini dhcp-snooping config on a rather ancient 5500ei and I'm getting the same results. 

I can see plenty of activity if I have "debugging dhcp-snooping all" and "term deb" set in the user view. Nothing terribly helpful to suggest DHCP offers being blocked which is what I was looking for when I suggested the debugging above. 

I can prove that the dhcp offers are being blocked in the sense that they will work from the rogue router on a trusted port and subsequently don't work on an untrusted port. However I have no logging in syslog and no traps to SNMP (both going to IMC) to give me an audit trail that the offers were actually blocked from the rogue. A PoE phone will sit indefinitely waiting for an IP if the only DHCP server around is the rogue on an untrusted port.

The offers ffom the rogue seem to be silently dropped - and seeing as I don't have an additional "log" option for dhcp-snooping under CW5 I think I'm now a bit stuck. 

I have experienced something similar where the ACL deny rules worked perfectly but the logging of the rule "hits" weren't getting put anywhere and we only got counters but my memory is a bit fuzzy on that one and I can't remember the platform nor the exact circumstances. 

Hope that gives you a little reassurance - happy to try something if you think of a different angle of attack.

Cheers

Ian

[lunitin]

I updated to 3113P05 and still don't see any log related to drops. I also tried undoing the log setting on ipv6 and re-enabling ipv4 to no avail.

As you experienced, with debugging dhcp snooping all I can see a DHCPDISCOVER from a client, but there is nothing relating to the processing and dropping of rogue DHCP packets. 

Well, at least the feature works =)