Post-Kaminsky DHCP thoughts.

David W. Hankins David_Hankins at isc.org
Fri Aug 15 15:02:40 UTC 2008


If a ne'er do well can Kaminsky a cache record for WPAD.yourdomain,
then they might be able to become the man in the middle for a
significant portion of your users traffic (at the very least, DOS'ing
their Windows Updates, more if they've manually enabled automatic
proxy detection in their browsers).

Even if you're not using WPAD, your clients still are.  Especially if
you aren't using WPAD, the DNS method of finding the WPAD
configuration is basically garbage-packets.  Repeated queries that
can't ever succeed.  And the DHCPINFORMs are just needless noise.

I've discovered that you can 'poison pill' Windows WPAD
implementations by sending "\n\000" on option code 252 (config
below).  In addition to stopping them from ever sending a DNS
packet, this also halts the DHCPINFORM behaviour if you put code
252 onto the PRL.

It can't hurt to just carry this config, and it might do some good.


# WPAD definition
option wpad code 252 = text;

# Suppress WPAD activity - no cache, no DNS.
option wpad "\n\000";

# Configure a valid WPAD cache.  The \n is required for Windows.
# All config below this line is optional.
#option wpad "http://www.example.com/wpad.pac\n";

# Special config for Windows ("MSFT 5.0") systems.
# Note this does not catch Windows CE.
class "MSFT" {
  match if substring(option vendor-class-identifier, 0, 4) = "MSFT";

  # They put 252 on the DHCPINFORM's, but not on the DHCPREQUEST's
  # PRL.  So we over-ride the PRL to include 252 = 0xFC, which will
  # send the option at DHCPDISCOVER/DHCPREQUEST time, and wil also
  # suppress the DHCPINFORMS!  They seem to cache it.
  option dhcp-parameter-request-list =
                       concat(option dhcp-parameter-request-list, fc);
}

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins


More information about the dhcp-users mailing list