There is still no official update from Google providing details of the "Aurora" attack, but we continue to see second- and third-wave attacks in our logs. As it looks like most of the host sites are using "Dynamic DNS" subdomains, I thought this would be a good time to write about this often-abused part of the Internet.
DynDNS domains are a special type of "Free Web Host". A traditional free host provides you with a certain amount of space on one of their servers, and some sort of toolset to manage your site (think of geocities.com in the "good old days" of the Internet; freehostia.com is a current example, but there are hundreds). You choose an available domain name, which becomes a subdomain of the main site: e.g., mycooldomain.freehostia.com. DNS queries come in for your subdomain to the main DNS server for the host domain, and it resolves the request to point to the directory on the server farm where your site lives. You upload some content, and you're up and running.
A DynDNS "hosting" approach is similar externally (you pick a name that will become a subdomain of one of the DynDNS host's domains: mycooldomain.dyndns.biz or someotherdomain.dnsalias.net, and their domain's DNS server will resolve it), but there is a key difference: they don't actually host your site (just the name). Your site actually lives somewhere else on the internet, often at a dynamic IP address such as you might have at home with your Internet connection. You simply update their database whenever your IP address changes (either manually or via a script), and people can always find your site (except perhaps for short periods of time during an address transition).
This is a useful solution for tech hobbyists who want to play around with hosting their own domains on their own boxes -- e.g., to learn how a web server works, with full control over the box. Such a hobbyist site is unlikely to have a large user community (often just the hobbyist and a few friends), and probably hosts very eclectic content.
However, this sort of hosting is also a useful solution for a Bad Guy, particularly one who has a network of "bots" that can serve as invisible web servers. Using a DynDNS host, the Bad Guy can point his newmalwaredomain.com URL at any of the bots, and let them take turns serving content. By rotating the assigned domain name among widely separated bots, he makes it harder for the Good Guys to figure out where his base of operations is.
Knowing this, we created an internal web filtering category called "DynDNS" over a year ago, and began making a distinction between domains there and those in our traditional "WebHost" category. Externally (that is, from the customer's point of view), the DynDNS URLs show up in the WebHost category, but internally, we can study how they are being used.
"And how are they being used?" you ask.
Well, for this blog post, I pulled sample sites from the past week's traffic logs, grabbed a random set of 100 sites, and took a look. Here's how it broke down:
| Count | Description |
|---|---|
| 25 | appeared to be legitimate sites (usually tech-oriented, as you might expect) |
| 24 | were DNS failures (i.e., the DynDNS host did not recognize the subdomain as valid) |
| 21 | timed out or returned a 404 (i.e., the host thought it was valid, but it never responded, or the server there says that the requested page doesn't exist) |
| 10 | were restricted-access pages in some way: either returning a 403 (not authorized) code or bringing up a password form blocking access |
| 2 | were Under Construction pages |
| 18 | were suspicious/shady in some way: a couple were hosting warez (audio files or movies), one was an open web proxy, and 15 had obvious junk/throwaway machine-generated names coupled with blank pages, 404s, or were abandoned |
| 0 | instances of malware or malware links were found (although of course some of the shady-name abandoned sites may have had malware on them originally) |
(As you might expect, none of these sites had more than a few hits in the logs.)
Several of the "404" pages were actually from networks of sites that appear to be involved with affiliate clicks/sales of various goods (usually on Amazon). These used obvious machine-generated names (to be unique), most involving the "search terms" of the advertised goods. You get the 404 errors unless you have the proper "decorations" in your query. These appear to be non-malicious, just a bit on the "possibly scammy" side. Some examples were:
So what can we conclude? Obviously, this sort of "hosting" tends to involve sites with short lifespans, but it's hard to argue from the log data that there is a hugely elevated risk of malware that would justify a blanket rating of "Suspicious" or "Malware" for all DynDNS sites.
However, it is relatively easy for an individual customer (especially a business customer with above-average security needs) to make an argument for blanket-blocking all DynDNS domains, due to a lack of a strong business case for leaving them unblocked. There simply isn't a lot of valuable content out there in this ecosystem. (Of course, that's true of a lot more of the Internet than just DynDNS sites, but still...)
The only exception that I can see for a business might be a special-purpose tech site (possibly even set up by the customer's own IT staff) for testing purposes, or for access to a particularly esoteric but vital type of data -- and the small number of these could be whitelisted as needed.
Accordingly, I'd be interested in hearing from customers who would like the option of being able to blanket-block DynDNS sites. Is this something you would want?
Posts
No comments:
Post a Comment