July 2008 Archives

Well as I'm sure everyone is aware the details of the DNS flaw that Dan Kaminsky found have been disseminated round the 'net a bit early.

I'm not going to get into the politics of whether that's a good thing/bad thing or how urgent patching is as it's been done to death elsewhere...

I was thinking though about how it may be possible to mitigate this in other ways than patching...

Having heard the detailed explanation from matasano on the vulnerability, wouldn't it be possible to mitigate this by changing the behaviour of the authoritative name server..?

If I'm understandning things correctly as the authoritative name server for a domain you'd see a whole load of requests for invalid subdomains to your domain (eg, AAAA.MYDOMAIN.COM AAAB.MYDOMAIN.COM) and usually you just respond with NXDOMAIN. Now the attacker is relying on you responding NXDOMAIN so he can respond with the additional RR of your real website, say, WWW.MYDOMAIN.COM.

Would it be possible to change your behaviour to respond as the attacker would do with the RR for your valid hosts, so causing the caching DNS server to cache them on the first attempt and preventing the attacker from getting the incorrect entries in first..? The attacker is relying on guessing port and transaction ID so won't get there in the first attempt, so it would seem that this would potentially mitigate the problem..

That said I'm no DNS expert so this may well be off base...

There's an interesting post at Hoffs blog around virtualization and DMZs and to what level it's "ok" to virtualize a given DMZ environment, following on from a white paper by VMware on the subject

As Hoff mentions you need to understand the wider context in any risk assessment, but I actually think that in the scenarios that VMware have painted out, I'd agree with Alessandro, that the fully collapsed DMZs talked about in the paper are a no-no.

And there's a nice risk assessment reasoning here, it's not just a "ooh hypervisors scary" kind of reaction, honest :) ..

So here's how it works. In the diagrams they've used they've laid out a picture of a number of security controls. The main one being separate firewalls segregating the Internet from each of the DMZs in turn. This would indicate to me that the risk assessment dictated that no one device should be a point of failure for the security being provided by the environment (a more cost effective, but traditionally seen as more risky design would be a single firewall with multiple interfaces, one for each network.)

So if we then introduce virtualization to this scenario then it seems that the option of a "partially collapsed" DMZ meets the security requirements as each DMZ has it's own VMware ESX instance and a compromise of the hypervisor won't result in a breach of DMZ segregation.

I think that in a lot of cases it's easy to look at virtualization as something new but it should be possible to look at the current risk appetite in an environment (are you using separate devices to segregate things, are you relying on VLAN tagging for separation) and then apply that to come up with the appropriate virtualization design.