Windows DNS and the Kaminsky bug

microsoft patches | Digg hot tags

microsoft patches | Digg hot tags — Thu, 04 Dec 2008 07:54:14 GMT

PingBack from http://diggwow.info/tags/108/200812/microsoft-patches.html

re: Windows DNS and the Kaminsky bug

Alun Jones — Thu, 04 Dec 2008 23:24:57 GMT

At http://msmvps.com/blogs/alunj/archive/2008/07/25/1642098.aspx, I talked about using the "ReservedPorts" registry entry documented in http://support.microsoft.com/kb/812873 to prevent the DNS server from binding to certain ports.

The SocketPoolPortExclusionList entry sounds similar, but would presumably be restricting only the DNS server, rather than "ReservedPorts", which restricts all servers from binding to those ports by accident.

Thanks for coming up with this extra information - cache locking sounds like a simple way to prevent this attack, but will be worth watching if any future attacks guarantee a cache can be poisoned, because now a poisoned cache will be poisoned for 50% of the declared TTL.

re: Windows DNS and the Kaminsky bug

sseshad — Fri, 05 Dec 2008 01:05:59 GMT

Hi Alun, yes the SocketPoolExclusionList applies only to the DNS server and not to any other services/applications. A possible issue that the SocketPoolExclusionList attempts to mitigate is that if application "x" for some reason always asks for port "p" in the 49k-64k range, but in this instance that port is taken away by the DNS server, then application "x" has nothing to bind to. This sounds a little bizzare, but in the event that it does happen, it will be really hard to detect the failure cause. The exclusion list can allow administrators to selectively control the socket pool based on what else is running on that machine.

re: Windows DNS and the Kaminsky bug

Alun Jones — Fri, 05 Dec 2008 02:13:28 GMT

Said bizarre reasons include attempts to restrict the number of ports used by RPC-dependent network services. Take AD, as an example, if you've followed the instructions in http://support.microsoft.com/kb/224196 in order to allow AD replication and client RPC traffic through on a fixed port, you may well have chosen a port in that range of 49k-64k, in an attempt to avoid opening the firewall up to a 1k-64k port range.

re: Windows DNS and the Kaminsky bug

Robert — Fri, 05 Dec 2008 09:31:33 GMT

The services offered by us provide a competitive advantage in several ways as it

increases the tempo of your business activities. <a href="http://www.realdataassistance.com/">Data entry service providers</a>

re: Windows DNS and the Kaminsky bug

someone — Mon, 29 Dec 2008 15:24:05 GMT

Please we are concerned about DNSSEC support in Vista and Server 2008. Please add it in the upcoming service pack. We don't like forced to upgrade for this feature.

re: Windows DNS and the Kaminsky bug

stopka2top — Fri, 20 Mar 2009 17:39:28 GMT

How do you control the value of this setting?

Ø Dnscmd /Info /SocketPoolSize will tell you the current size of the socket pool

blogs.technet.com/sseshad/archive/2008/12/03/windows-dns-and-the-kaminsky-bug.aspx

Ø Dnscmd /Config /SocketPoolSize <val> sets the socket pool size to #val

Ø Once you reset the size, you must restart the DNS service. Use net stop dns to stop the service, and net start dns to restart the service. Once the service has restarted, the new socket pool will come into effect.

re: Windows DNS and the Kaminsky bug

stopka2top — Fri, 20 Mar 2009 17:40:42 GMT

blogs.technet.com/sseshad/archive/2008/12/03/windows-dns-and-the-kaminsky-bug.aspx

re: Windows DNS and the Kaminsky bug

Michael — Wed, 01 Apr 2009 19:36:47 GMT

Hello,

We had DNS-Spoofing under Server 2003 R02 (All patches) in Switzerland since December 2008. The fix for this was released 10.03.2009 by MS. You can find traces about DNS Spoofing (Server 2003) from beginning Dec 2008 on Secunia and several security sites. I am a great fan of MS products and i kind of hate linux. Not because of TUX because of the strange people who manage it ;-)

But now: Why did it take 3 Months for MS to release i patch for the DNS Server?

On TUX it's one line of code to drop the packet (The Zero ones) out of everything. Sonicwall, Series 2, Zyxel could not filter it. Every Fortigate could do it since the beginning.

Can you imagine how much traffic and Peaks on larger ISP's MS has generated with this. Can you believe that several larger enterprise customer did change their ISP in this time?

I mean i have XX calls fre at MPSS because we are M S Partner. But do you just want me to call next and MAYBE we will get USD250 charged...

Can you imagine what an ISP tells you if you explain them that you run a NS not on Bind but a DNS MS 2003?

For fast answers and TUXIES

;-) No, we (some) can't because then Exchange 2007 CAS to be in the LAN Segment otherwise they guys from spain (MPSS) hang up the fone. No i don't like the experiments with Edge and ADAM.

You (Some other MS dudes) did some good work with "Malicious software removal" which saved some MCAFEE enterp* butts the last few weeks because of not deteting conf* but the DNS story sucks.

Thank you Microsoft.......

re: Windows DNS and the Kaminsky bug

John — Wed, 22 Apr 2009 09:50:50 GMT

Thanks! This is exactly what I was looking for, too bad MS didn't explain/post this as well...

re: Windows DNS and the Kaminsky bug

cheap propecia — Thu, 28 May 2009 09:36:53 GMT

If you have to do it, you might as well do it right

re: Windows DNS and the Kaminsky bug

GW@DellCSS — Fri, 19 Jun 2009 21:18:11 GMT

what collection of commands do we have, analogous to DNSCMD /config /socketpoolsize <value>, that will work on our few, but dogged Win2000server customers? DNSCMD /config is an unknown command, and we have to do something about the ~5700 handle count being sucked away from user mem. It has become a significant call driver for us whenever we see server freezes... and reducing socket pool size by 1/2 cuts the expended handles in 1/2 as well, resulting in resolution.