ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-ff-pdp-may08] Jump start on answering GNSO questions regarding fast flux

  • To: dave.piscitello@xxxxxxxxx
  • Subject: Re: [gnso-ff-pdp-may08] Jump start on answering GNSO questions regarding fast flux
  • From: Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>
  • Date: Wed, 2 Jul 2008 09:38:03 -0700

Dave mentioned:

#If there are legitimate uses of low TTLs, 

And of course there *are* legitimate uses, including the ability to rapidly
relocate network resources which may come under attack, assuming the attack 
targets a dotted quad and not a FQDN. (Targetting a dotted quad rather than
a FQDN is generally preferred by intelligent attackers because then you 
avoid creating a "steerable death ray" which can be repointed by whomever
controls the DNS for the targeted domain name)

By way of example, you may see some dot gov or dot mil sites running with 
low TTLs, and they are also quite common for content distribution networks
such as Akamai.

#then monitoring "low TTL" alone is not sufficient. 

Correct, although that *IS* something that should be noted as part of 
building an aggregate "score" for a potential fast flux domain.

I would suggest adding some additional factors for automated analysis:

-- How *many* dotted quads are returned? 

   Most fastflux domains will return multiple IP addresses, while this
   is far less common for non-fastflux domains. 

-- If you look at the in-addr's for those dotted quads, do you see rDNS
   naming consistent with consumer dynamic address space, such as rDNS
   patterns matching the rules on Steve Champeon's Enemies List? (see
   http://enemieslist.com/news/ )

   Or, alternatively, are the dotted quads listed on the Spamhaus PBL?
   The Spamhaus Policy Block List lists space that should not be emitting 
   mail direct to MX, however it can also be potentially "overloaded" 
   and used for an "off-label" purpose, e.g., to identify address space 
   which should ALSO not be serving web pages.

   Most fastflux domains will be hosted on compromised broadband-connected 
   consumer PCs living in dynamic address space listed on the PBL.

-- If you map the dotted quads to ASNs using the Oregon Route-Views 
   IP to ASN zone, do you see multiple ASNs? (Information on using the
   IP to ASN zone is included at www.uoregon.edu/~joe/one-pager-asn.pdf )

   Again, in my experience, most fastflux hosts will have IPs spanning 
   multiple ASNs.

-- If you look at the headers returned by the site, in many (but not all)
   cases, it will be using nginx to proxy the fastflux front end site to
   the real, backend, "master" web site 

   Just like the other factors, seeing a site using nginx is not fully 
   determinative in and of itself, but it should be considered as one of 
   a set of factors, helpful in aggregate when it comes to discriminating 
   the sheep from the goats. 

-- If you look at the name servers used by the potential FF domain,
   they themselves will often be running on dotted quads seen used in 
   conjunction with other potential FF domains

   The IP addresses of those name servers will also often be listed on 
   the Spamhaus SBL

   You will also often see multiple potential FF domains clustering on
   the same name server domains or dotted quads

   The name servers may also exhibit behavior consistent with "wildcarding"

-- If you look at the domain whois associated with the potential FF domain,
   it will often either be hidden behind a whois privacy service, or
   have "low quality" (verifiably incorrect, inconsistent or incomplete)
   point of contact data

-- if you look at the age of the domain, you will see that it was 
   typically recently created or updated

If you're able to monitor a potential fastflux domain over time, things
get even easier since, well, fastflux domains *change over time*. I'm 
not sure I can think of *ANY* legitimate site that uses more than a
couple dozen IPs while also meeting the other criteria mentioned above.

#SSAC also suggested rate limiting. I'm not crazy about this option. It 
#seems like it could be circumvented by the attackers if they simply used 
#many more domains for name servers.

Require static glue records for name servers, and require a fee for changes
made to those glue records. Voila, fastflux per se disappears. 

#We also need to consider whether any policy that focuses on TTL will 
#simply incent the attackers to adopt a different strategy. 

You're really asking, "*Why* do the bad guys publish records with short
TTLs?"

The answer is, "Having short TTLs allows them to delete dotted quads
which are associated with systems that are no longer accessible/usable,
while also making it possible for them to avoid staying on any one 
system long enough for the ISP or law enforcement to do lawful intercept,
thereby identifying the upstream connection coming out of that compromised 
host.""

Assuming that analysis is correct, and short TTLs magically become
impossible, the bad guys are then likely to look for dotted quads which 
have a proven track record of being relatively static, on providers with 
poor network instrumentation, in countries with glacial cyber law 
enforcement.

And if that's impossible, and everything suddenly becomes crazy efficient,
I *think* the bad guys would just multiplex their cr*p over more domain 
names, getting survivability and redundancy by mapping more domains to 
a wider range of FQDNs (all still hosted on compromised consumer systems)

Short TTLs are *convenient* for the bad guys/gals, but short TTLs are by 
no means *required* to enable website hosting or DNS hosting on 
compromised PCs...

Regards,

Joe

Disclaimer: all opinions strictly my own



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy