[dns-operations] Client Side Issues
simonw at zynet.net
Fri Jul 25 15:42:37 UTC 2008
On Friday 25 July 2008 15:45:54 Jon Kibler wrote:
> By default, all windows systems run a service call DNS Client. It is my
> understanding that this is a caching resolver. Is this vulnerable? Has
> Microsoft patched it? (I have never seen a need for this service, so for
> a couple of years now, I have been advising my clients to disable this
> service via a group policy.)
It is a local name cache. It improves performance for name lookup.
Microsoft released patches for client (stub resolver) only systems. So I
assume they fixed this when they broke Zone Alarm, I haven't checked yet.
The Checkpoint website still suggests uninstalling the relevant Microsoft hot
fix as a workaround for the Zone Alarm problem. Is that good security advice?
It looks like Microsoft also rolled in another undisclosed DNS poisoning
vulnerability fix to some patches, but without knowing what the CVE numbers
refer to this is guess work on my part.
> I have never really spent any time looking at the BIND light weight
> resolver. Is is similar to the Windows DNS Client software? Are there
> vulnerability issues with it?
Patches were released for various resolver libraries.
Looking at systems here, I see older Linux stub resolvers using the same port,
and patched ones using apparently random ports.
> I guess these questions really should be more general: What are the
> client side issues to with this vulnerability, what should be done about
> them, and are all the client side resolvers patched?
Step one - prevent spoofing.
If you prevent spoofing of your recursive resolvers on your networks, then the
only clients vulnerable are those choosing to use recursive resolvers on
remote networks (OpenDNS users for example).
For enterprises this means closing traffic to and from port 53 except for name
servers. For ISPs it is more complex.
Realistically I can not, and will not, patch all our internal stub resolvers
systems in the foreseeable future (and there aren't that many!). Some are
firmware based, some are on unsupported OS versions for a reason (that reason
is sometimes risk v cost, or lack of resources). Thus the only sensible
strategy is to mitigate the threat via other means. In almost all cases this
means stopping spoofing, and regulating port 53 traffic at chokepoints.
Other approaches welcome. [Maybe a new job with less diverse systems, and more
time to dedicate to system maintenance]
Possibly rate limiting might work in some situations, like it did for ICMP
DDoS floods, I'd be wary of rate limiting port 53 traffic too heavily,
although if it was important recursive resolvers will try again in a few
That said DNS spoofing is a lot of work to compromise one client system, so I
assume the bad guys will target unpatched recursive resolvers first for big
operations (phishing), and the spoof attacks on individual stub resolver will
be reserved for more targetted abuse, or for when all the big recursive
resolvers are already patched or owned.
More information about the dns-operations