DNS relay servers

This one maybe boring security for some, but a lot of people I meet who claim to be in security forget the very important, possibly critical CIA model of security. No I don't mean the Central Intelligence Agency, I mean Confidentiality, Integrity and Availability. These three things are the key to good security infrastructure, and DNS is part of at least the last two.

Generally speaking if you are a small to medium business, you will have a DNS server in your environment. You could just leave it as default pointed to the root servers to do external resolutions for your clients, but in geographically disperet countries like Australia that can lead to resolutions failures due to the latency to the root servers that is sometimes experienced. If you have a big enough pipe this latency is manageable and won't cause an issue, though a bit of contention can begin to cause problems. My suggestion was usually to specify DNS relay servers. This allows you to relay your requests to your ISP, especially good if your ISP blocks lookups to the root servers which I have also seen. But should you just specify your ISP's DNS... well when I first started doing this that is what I did. Till the ISP the client was using had their DNS cache poisoned and a few popular sites started coming badly, and other times where the ISPs DNS failed or changed without notice.
So I started setting a second or third that was with a different ISP, but was known publically accessable, either Optus or Telstra as they are/were our biggest ISP's in Australia at the time. I eventually started also adding OpenDNS and googles DNS to my reportaire, especially OpenDNS's premium services with clients that wanted the blocking that a proxy gives without the infrastructure or upfront cost, yes I know you can get round it by simply knowing the ip of a malicious site, but it was better than unencumbered internet feeds. I am not a shill I don't even have an OpenDNS account anymore.

This worked very well. But just today while troubleshooting an issue I fired up WinMTR, a windows port of the Linux tool Multi-Trace-Route (MTR), very useful at finding a hop in your route that could be having issues. As usual I used these memorised Optus and Telstra DNS servers to check my routes and I found packet loss (there was an issue with my ISP's bridging router into PIPE it seemed). Then I tested to my ISP's DNS, all good no packets dropped and only 4 hops, then I thought hmm I should test to googles open DNS servers, just to see;
|-----------------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                                                   |
|                       Host                  -                  %  | Sent | Recv | Best | Avrg | Wrst | Last |
|-------------------------------------------------------|-------|-------|-------|-------|--------|-------|
|                  x-x-x-x.tpgi.com.au -                  0 |      5 |    55  |      1  |      3 |      81 |      4 |
|                 x.x.x-x.tpgi.com.au -                    2 |    55 |    54  |     23 |    28 |    114 |    24 |
| syd-nxg-men-crt2-ge-3-1-0.tpgi.com.au -    0 |    55 |    55  |     48 |    69 |    159 |    67 |
|                            202.7.171.46 -                    0 |    55 |    55  |     25 |    33 |    124 |    28 |
|                            72.14.237.21 -                    4 |    55 |    53  |     26 |    28 |      43 |    32 |
|          google-public-dns-a.google.com -       2 |    54 |    53  |     44 |    70 |    151 |    76 |
|_____________________________________|______|______|______|______|______|
   WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir  ( stanimir@cr.nivis.com )

Yeah there is a little packet loss there, issues with my connection, but only 6 hops is impressive. It wasn't this way when it first started, I remember using google dns early on and seeing latency of 100+ms and about 10-15hops, I quickly realised of course they are google, they are now using Anycast, a quick traceroute from elsewhere in the world (thanks to centralops tools)confirmed this due to the different route (more hops lower response time, but the first 5 are internal);

1

1

1

1

70.84.211.97

61.d3.5446.static.theplanet.com

2

0

0

0

70.87.254.1

po101.dsr01.dllstx5.networklayer.com

3

0

0

0

70.85.127.105

po51.dsr01.dllstx3.networklayer.com

4

2

0

0

173.192.18.228

ae16.bbr02.eq01.dal03.networklayer.com

5

0

0

0

173.192.18.208

ae7.bbr01.eq01.dal03.networklayer.com

6

0

0

0

50.97.16.37

7

1

0

0

72.14.233.77

8

1

1

0

72.14.237.219

9

7

7

7

216.239.47.121

10

7

7

7

216.239.46.59

11

*

*

*

12

7

7

7

8.8.8.8

google-public-dns-a.google.com

So, moral of the story. If like me you are using one of the aformentioned or external DNS in replacement or addition to your ISP, now is a good time to move to Googles DNS, as it is probably faster than everyone else bar your ISP, and gives you a bit of redundancy. As one of my colleagues used to joke, if Google is down, the internet is down.
I did read something interesting in my travels researching this, Geographic aware DNS (aka GeoDNS), there is a patch for Bind and a fork of DJBDNS here; http://geoipdns.org/. Interesting, it is a similar idea I discussed with a colleague a few years ago and tested implementing in a kluge style way with Microsofts DNS server, this implementation is a lot smoother however.

Oh and there is an update to my previous post on 1.5 factor auth.

Definately not outage Virgins

So in case you haven't heard an international budget airline here in Australia has had a major computer issue, see here.
By the sounds of it their outsourced service provider doesn't have redundant kit, as they couldn't simply fail-over. But it gets worse currently going to https://book.virginblue.com.au/FlightInfo.aspx or https://book.virginblue.com.au leaks a lot of information, and leaks a nice juicy standard ASP.Net error page, of the type that the recently discussed Asp.Net oracle padding attack can take great use of, see here.
Ouch and double ouch. Oh and we hear this is not the first outage they have had in as many months...

Revocation, just rolls off the tounge

First an overview, SSL is pretty much the only protection available when banking, shopping etc. It means the user has to look for the https:// up the top rather than the http:// to ensure the session from their browser to the websites server is encrypted in transit (this isn't perfect people can fake some certificates, and security researchers are trying to find its holes all the time). Don't trust the lock or the little green bar that EV certs give you as these can be faked several ways, generally though the https and certificate information can be trusted. Also look at an extension for FireFox called SSL blacklist for FireFox that will notify you if a certificate is bad due to one of many reasons.
One of the interesting things about certificates is of course they have to be able to be revoked, when for some reason they become compromised or some such other reason.
CRL or certificate revocation lists as some are probably aware are basically a list stored on the company that provided the certificates website, basically a list of all the certs that have been revoked. Excellent idea, but look at most certificates details and CRL is hosted on a good ole plain http site eg; http://crl.thawte.com/ThawteSGCCA.crl
YAY, so if you want just own a few crl via DNS poisoning or man in the middle (MITM) a user (can we say web cafe) and serve up a fake crafted CRL to revoke heaps of certificates or just remove your revoked cert for their bank etc. Of course there are a lot of variables here, you need to know the CRL that is going to be requested though if you have MITM'd them you can just serve all of them up, they are usually signed, but not always, you also need to know sites they are going to go to, but you can dynamically do this as well.
Their digital signing doesn't look that good from what I have seen from reading the crl's either, but they are supposed to sign it with their SSL certificate available from their site via a link, so no trust their just sign it with your own cert and serve that up at their site as you are already in the middle.
But the nice thing as far as a denial goes is that most operating systems cache this info (for 24 hours usually), and the Certificate hierarchy is good just blacklist the vendors root certificate.
To do any real damage you still need to get a certificate registered that has been falsely registered, or do a bit of social engineering, blacklist all certs and pop up a page saying the user needs to update their certificates, redirect them to a legit looking site that asks them to install a certificate package full of your own generated root certificates, all SSL sites from then on are readable as you re-sign them with your key on the way through.
Of course SSL isn't a fix for the revocation lists as no one will see that it requests the list from https instead of http, I have even seen some installs of Internet Explorer that have certificate revocation checking turned off, I am not sure if this is default, but bad none-the-less.

Well I hope this long winded odd rant is at least made some people think. It is a very odd setup and I am surprised all CRL's don't require possibly multiple signing by at least two vendors kind of like nuclear launch codes.