DNS port randomization

[dpoon]

As announced in CERT advisory #80013 (http://www.kb.cert.org/vuls/id/800113) and CVE-2008-1447 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447), making DNS queries with predictable source ports makes us more vulnerable to DNS cache poisoning attacks than previously thought (http://www.circleid.com/posts/87143_dns_not_a_guessing_game/).

On the several VPSs that I have, RimuHosting has populated /etc/resolv.conf with the following nameservers:

206.123.64.245 (ns1.colo4dallas.net)
72.29.96.250 (ns3.colo4dallas.net)
207.210.212.202 (ns4.colo4dallas.net)
207.99.0.1 (dns1.nac.net)
207.99.0.2 (dns2.nac.net)


Of the six nameservers (if I also include ns2.colo4dallas.net), only dns1.nac.net currently has adequate source port randomization.

I'd like to know, what steps are RimuHosting and its colo providers taking to implement DNS source port randomization? I know I can work around the problem by running my own DNS or by pointing all of my VPSs to dns1.nac.net, but I'd prefer to avoid these suboptimal solutions if there are already plans in place to upgrade the provided nameservers.

[hsalgado]

I agree. The test from my VPS gives:

% dig porttest.dns-oarc.net in txt +short
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b. a.pt.dns-oarc.net.
"72.249.0.34 is POOR: 26 queries in 1.2 seconds from 1 ports with std dev 0.00"

In resolv-conf I got:
nameserver 72.249.0.34
nameserver 206.123.69.254

Thanks.

Hugo

[bchecketts]

Those name servers are run by our data centers, so are out of our control. Beginning in June, we have our own recursive servers that new VPS's should be configured to use. You can change the name servers for your VPS to use these:

72.249.191.254 Dallas, Cogent
206.123.113.254 Dallas, Internap (should only be used on Dallas machines)
66.199.228.254 New York
92.48.122.126 London

These servers run PowerDNS, which is listed as 'Not Vulnerable' on the security advisory at http://www.kb.cert.org/vuls/id/800113. In addition, I tested them with the same test that you used, and they all come back as 'GOOD':

staff:~# dig @72.249.191.254 porttest.dns-oarc.net in txt +short
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b. a.pt.dns-oarc.net.
"72.249.191.254 is GOOD: 26 queries in 1.7 seconds from 26 ports with std dev 16981.55"

staff:~# dig @206.123.113.254 porttest.dns-oarc.net in txt +short
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b. a.pt.dns-oarc.net.
"206.123.113.254 is GOOD: 26 queries in 1.2 seconds from 26 ports with std dev 19335.08"

staff:~# dig @66.199.228.254 porttest.dns-oarc.net in txt +short
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b. a.pt.dns-oarc.net.


staff:~# dig @92.48.122.126 porttest.dns-oarc.net in txt +short
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b. a.pt.dns-oarc.net.
"92.48.122.126 is GOOD: 26 queries in 4.1 seconds from 26 ports with std dev 14822.64"

Thanks,
Brandon Checketts
RimuHosting.com

[Lloyd]

I really had no idea what the "DNS poisoning attack" vulnerability was about, so went investigating, and found some pretty good explanations here:

http://www.kb.cert.org/vuls/id/800113
and here: http://www.trusteer.com/bind9dns

I'm not an expert on DNS, although I do run my own master/slave DNS servers. If I am overlooking something, please correct me:

I don't see how naming spoof-resistant DNS servers in resolv.conf on our VPS's is going to make much difference. I think the main use of DNS for a VPS is resolving done by the mail server, and for applications you run via ssh and via cron on your VPS, like lftp. rsync uses ssh authentication and is not vulnerable, I think. And I don't think a web server uses DNS at all.

The way I understand it, DNS poisoning is a "man in the middle" attack. A caching nameserver is tricked into accepting and storing a bogus DNS record (IP) that leads to to bogus site that could steal customer information. After the DNS poisoning, subsequent DNS queries for the affected record would continue to return the bogus information until the TTL is reached and the record expires.

If you are afraid of having your website customers sent to a bogus website through DNS poisoning, it is the customers' caching DNS servers (usually ISP-supplied) that you would worry about, not your VPS's DNS. And of course you probably cannot do anything about your customers' DNS.

I checked my Rimuhosting VPS's DNS servers (run by the data center) and yeah, they don't use port randomization and so are "poor" at resisting DNS poisoning attacks. However, I can't imagine a scenario where using a more spoof-resistant DNS server for my VPS would improve anything, so I left my resolv.conf nameservers alone.

I run a Apache webserver for several sites, Postfix mail server, vsFTP, and bind9. My bind9 nameservers are *not* caching, except for connections from my ISP's network. (That is, in addition to being authoritative for my domains, I use my bind9 servers for my home PC's DNS. I had a lot of trouble with my ISP's DNS before I started doing that!)

If I am missing something, someone please explain.

[Lloyd]

My VPS had, in resolv.conf, the following:
nameserver 72.29.96.250
nameserver 207.210.212.202
nameserver 207.99.0.2

I accidentally changed this to:
#nameserver 72.29.96.250
#nameserver 207.210.212.202
nameserver 207.99.0.2
nameserver 72.249.191.254
nameserver 206.123.113.254

That put 207.99.0.2 in first place. Those last 2 nameservers are new PowerDNS Rimuhosting servers.

Then in my logs the following named errors appeared:
unexpected RCODE (REFUSED) resolving 'puppylinux.com/AAAA/IN': 207.99.0.2#53: 1 Time(s)
unexpected RCODE (REFUSED) resolving 'f.l.google.com/AAAA/IN': 207.99.0.2#53: 1 Time(s)
unexpected RCODE (REFUSED) resolving 'scs.msg.yahoo.com/A/IN': 207.99.0.2#53: 1 Time(s)
unexpected RCODE (REFUSED) resolving 'evidenceofhumanity.org/A/IN': 207.99.0.2#53: 1 Time(s)
etc.

So it seems nameserver 207.99.0.2 is not accepting queries from my Dallas IP (72.249.38.123).

Also, I can see that there's quite a bit more resolving going on in my VPS than I expected.

[bchecketts]

Lloyd, as you noticed, your server does more resolving that most people realize. A couple example situation that might prove very catastrophic would be if you tried to do system updates (ie: an apt-get update, or yum update) and got updates from a malicious server.

Also, people use their servers for a wide variety of purposes, and just generally not being able to trust that you are talking to who you think you are is a bad thing.

You also noticed that 207.99.0.2 is not resolving queries from Dallas. That server is not under our control, so I'd recommend using 72.249.191.254 and
206.123.113.254 - which are the recursive servers we've created for use there.

Thanks,
Brandon Checketts
RimuHosting.com

[Lloyd]

Hello Brandon,

I had an IM exchange with Peter and he helped me see that there *are* circumstances in which the "DNS cache poisoning" threat could affect a server. (I could only think of the scenario of duping web *browsers* into visiting bogus sites.)

Here's a dangerous situation I thought of:
A web server could contact a credit card processor to process a credit card payment. A poisoned resolv.conf nameserver DNS cache could lead to credit card information being stolen!

(Of course, even if the resolv.conf nameserver is "secure," there may still be a compromised caching nameserver further along on the path to the authoritative nameserver.)

I have updated my resolv.conf nameservers as you recommended.

Thanks,
Lloyd