3

Is there a way to detect and more importantly block a malicious client from running a dhcpd instance after authenticating to the wireless.

We have a wlc but the APs are in L3 capwap mode with local routing. No tunnelling of the client traffic through the wlc. Reason is should the wan towards the remote site fail, the remote clients could still use the wireless network at their site.

Port-sec/source-guard/dai is implemented on the L2 switches access ports but the wireless trunks have been trusted as the wireless clients could not effectively roam between the access points.

I would really appreciate some help.

Improve this question
5
  • It's not perfect, but have you tried pushing an ACL to the AP's wireless interface, which blocks all traffic sourced from port udp/67?
    – Mike Pennington
    Mar 25, 2015 at 10:25
  • That is an excellent option worth investigating :-) A google search on this option returned some documentations interestingly the integration with ISE and also this link below. Setting up a test bed is the next step now. Thanks Mike! The web page is cisco.com/c/en/us/support/docs/wireless-mobility/wlan-security/…
    – user4565
    Mar 25, 2015 at 20:11
  • do your access point work as bridge or router ? can they block IP traffic when in bridge mode ?
    – Jorge Aldo
    Mar 27, 2015 at 0:20
  • 1
    @Jorge - They are in H-Reap mode.
    – user4565
    Mar 27, 2015 at 22:06
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin ♦
    Aug 11, 2017 at 14:55

2 Answers 2

Reset to default
2

One sure (but possibly not optimal/practical) way is to always have a faster dhcp service in place so that even if they try to offer DHCP responses, yours will get to the clients first and theirs will be ignored. Without the wlc there aren't a lot of filtering options at your disposal. The "right" option would be to drop either DHCP-REQUEST outbound the AP WLAN, or DHCP-OFFER in on the AP WLAN (either would stop a wifi dhcp service from being useful but not stop normal dhcp client traffic) but I have never seen that done at that level.

Improve this answer
2
  • Thanks Jefff, In a test bed I'm going to combine your answer to drop the dhcp-offer ingress with Mike's idea (in the comment above) to configure an acl that is pushed to the APs. But I'm still open (googling) to other options for protecting the clients, there are possibly more ways to do this.
    – user4565
    Mar 25, 2015 at 20:22
  • sorry but dhcps are not ignored. theres nothing on the protocol which could prevent a client from ignoring the first server to send an dhcp_offer.
    – Jorge Aldo
    Mar 27, 2015 at 0:21
2

Is there a way to detect and more importantly block a malicious client from running a dhcpd instance after authenticating to the wireless.

This is not a perfect solution, but use the WLC to push an ACL to the AP's wireless radio interfaces; the ACL should block all traffic sourced from port udp/67.

You don't want to do this with an autonomous access point's BVI interface for all the obvious reasons.

Improve this answer
3
  • This could be the solution as we have hundreds of WAPs across many sites. Pushing the acl to a soon to be created test bed and ensuring the clients aren't affected by the acl. Thanks Mike.
    – user4565
    Mar 27, 2015 at 22:20
  • Am I missing something? I'd just enable DHCP snooping on the edge switches, and only configure the uplink port as a trusted port...
    – Peregrino69
    Mar 29, 2015 at 17:01
  • 1
    @Mike Pennington. Cisco Tac came back with exactly your solution. Creating an acl to deploy that blocks dhcpoffers from wireless clients is the way to do it.
    – user4565
    May 27, 2015 at 20:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.