Missing the Wood for the Trees

February 15th, 2009 at 20:47 UTC by Richard Clayton

I’ve just submitted a (rather critical) public response to an ICANN working group report on fast-flux hosting (read the whole thing here).

Many phishing websites (and other types of wickedness) are hosted on botnets, with the hostname resolving to different machines every few minutes or hours (hence the “fast” in fast-flux). This means that in order to remove the phishing website you either have to shut-down the botnet — which could take months — or you must get the domain name suspended.

ICANN’s report goes into lots of detail about how fast-flux hosting has been operated up to now, and sets out all sorts of characteristics that it currently displays (but of course the criminals could do something different tomorrow). It then makes some rather ill-considered suggestions about how to tackle some of these symptoms — without really understanding how that behaviour might be being used by legimitate companies and individuals.

In all this concentration on the mechanics they’ve lost sight of the key issue, which is that the domain name must be removed — and this is an area where ICANN (who look after domain names) might have something to contribute. However, their report doesn’t even tackle the different roles that registries (eg Nominet who look after the .UK infrastructure) and registrars (eg Gradwell who sell .UK domain names) might have.

From my conclusion:

The bottom line on fast-flux today is that it is almost entirely associated with a handful of particular botnets, and a small number of criminal gangs. Law enforcement action to tackle these would avoid a further need for ICANN consideration, and it would be perfectly rational to treat the whole topic as of minor importance compared with other threats to the Internet.

If ICANN are determined to deal with this issue, then they should leave the technical issues almost entirely alone. There is little evidence that the working group has the competence for considering these. Attention should be paid instead to the process issues involved, and the minimal standards of behaviour to be expected of registries, registrars, and those investigators who are seeking to have domain names suspended.

I strongly recommend adopting my overall approach of an abstract definition of the problem: The specific distinguisher of a fast-flux attack is that the dynamic nature of the DNS is exploited so that if a website is to be suppressed then it is essential to prevent the hostname resolving, rather than attempting to stop the website being hosted. The working group should consider the policy and practice issues that flow from considering how to prevent domain name resolution; rather than worrying about the detail of current attacks.

Entry filed under: Security economics

6 comments Add your own

  • 1. Philip Virgo  |  February 15th, 2009 at 22:08 UTC

    Thank you for raising the role of the registries and registrars so clearly

  • 2. Clive Robinson  |  February 16th, 2009 at 16:02 UTC

    Richard,

    Although I agree suspension of the domain naime would be an effective method of dealing with the current Fast-Flux.

    I suspect that the method chosen is likley to be problematic.

    For instance how does a LEO in one place convince a registry else where that their request is legitamate and not somebody trying a DOS attack.

    Furtherthere is the question of legal liability.

    I can see this simple solution hitting a significant quagmire if the correct suport structure is not put in place first.

    And with all things involving potential liability I suspect it will be argued to death to avoid taking any action 8(

  • 3. Richard Clayton  |  February 16th, 2009 at 16:14 UTC

    @Clive Although I agree suspension of the domain naime would be an effective method of dealing with the current Fast-Flux.

    It is in fact what is done today; nothing else works!

    @Clive For instance how does a LEO in one place convince a registry else where that their request is legitamate and not somebody trying a DOS attack.

    Well indeed — exactly the sort of thing that a working group could start to thrash out, and start drafting Best Practice for.

    @Clive Furtherthere is the question of legal liability.

    Absolutely, if someone dumbly asks for “geocities.com” to be removed, and the registrar slips up, then the requester should take some of the blame. If that means damage$, then so be it.

    In practice, it is immediately obvious to the competent which are the 20 domains a day that need to be rapidly suspended, and although the bad guys always have the option of bringing the take-down process into disrepute — provided that a little bit of care is taken, there should be no problem. Once again, there’s a role here for WGs in writing Best Practice and suggesting what level of damage insurance might be appropriate to obtain.

    viz: a WG is just the sort of place to do _process_ and _best_practice_ work. It’s seldom (unless absolutely the right set of people are brought together) the place to do engineering or research.

  • 4. Richard Johnson  |  February 17th, 2009 at 17:00 UTC

    I dearly wish the takedown aficionados would cease their conflation of domain registration with DNS service.

    I’ve seen this most frequently in the noisier anti-spam crowd. They’re more concerned with making others jump at their command than they are with effectiveness. As a result, when they succeed in coercing a registrar into de-registering a domain, they do actual harm to anti-spam work.

    The harm is caused by removal of useful, known tags (the spammed, phished, etc. domains) from our filtering decisions and our monitoring.

    The thesis of your post is nearly as damaging to our efforts. Accordingly, please step back a bit, and make sure you’re taking the right tree. Don’t knock down the whole grove unnecessarily; others of us rely, for our mutual protection, upon it remaining there.

    You don’t have to advocate removing the useful (even necessary) sigil provided to us by the domain name to accomplish disabling the botnet. All we need to do is turn off the DNS service necessary for the botnet operation.

    Please make that distinction (DNS service is separate from domain registration), and help minimize the harm otherwise done to our ability to protect ourselves from that botnet.

    Thanks!

  • 5. Richard Clayton  |  February 17th, 2009 at 17:21 UTC

    @Richard All we need to do is turn off the DNS service necessary for the botnet operation.

    This means, for current attacks, ensuring that the domain is not present in the TLD zone, since everything below that is in the hands of the criminals. I agree that it doesn’t matter then whether the domain is made available for others to register (though given its history they’d be unwise to purchase), or whether the registrar attempts to monetise it by keeping it in the zone, but with name servers that direct traffic to advertising pages.

    My point is that either the registry or the registrar has to do something to the TLD zone — nothing else will work reliably, and the WG suggestions relating to lifetimes, TXT records, whois data and so forth don’t do anything to change the zone contents.

    As to the suggestion that the domain doesn’t need to be removed because filters are so ubiquitous and perfect that the domain no longer is of value… that’s far from universally true. Yes our data does show that some of the gangs employ new domains even when old ones are not yet removed, but other attackers clearly don’t change to new domains until they have to.

  • 6. neill  |  February 23rd, 2009 at 07:52 UTC

    changing the DNS system will NOT help at all – botnets could work very well with thousands of hardcoded IPs in their code, that send out IPs of compromised systems that belong to them
    think of bittorrent: trackers hand out IPs of participating systems, without ever using DNS (the only time one needs DNS is to find a list of trackers (e.g. in sweden))

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Subscribe to the comments via RSS Feed


Calendar

February 2009
M T W T F S S
« Jan   Mar »
 1
2345678
9101112131415
16171819202122
232425262728