Re: [gnso-ff-pdp-may08] Re: [ntfy-gnso-ff-pdp-may08] FW: example: using fast-flux to escape censorship
- To: dave.piscitello@xxxxxxxxx
- Subject: Re: [gnso-ff-pdp-may08] Re: [ntfy-gnso-ff-pdp-may08] FW: example: using fast-flux to escape censorship
- From: Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 16 Jul 2008 08:48:26 -0700
# * fast flux: an attack technique that involves rapidly changes the
# bindings of IP addresses to domain names, typically to prevent
# detection of hosts operating illegal or unauthorized services
# (DNS, mail, web)
[can we standardize on a single orthography for the phenomena, too?
I'm routinely seeing flux, fast flux (with a space), fast-flux (with
a hyphen, fastflux (compound word, no space) -- of those, I'd prefer
fastflux become the standard if at all possible, if only because it
google's best. I would also recommend FF as an abbrevitaion if you
get tired of typing f-a-s-t-f-l-u-x over and over and over again]
But coming back to the meat of your definition, Dave, it misses some
*crucial* elements of true fastflux:
-- fastflux hosts aren't used to preclude the DETECTION of compromised
hosts offering illegal or unauthorized services, fastflux is used
to prevent the complete TAKE DOWN of the service being offered via
fastflux. we can detect the dang things just great, we just have a
hard time tearing them all down (and thus taking the associated domain
off the air); doing so typically requires taking the domain down
instead, but that's difficult to do without cooperation of the
-- the network service offered over fastflux may not be inherently
illegal (e.g., there's nothing illegal about HTTP per se), but the
GOODS or SERVICES offered via that legal service may be HIGHLY
illegal (child pr0n, malware, pirated software or other intellectual
property, narcotics or other controlled substances being offered
for sale over the Internet without a valid prescription, etc.)
-- unlike conventional web hosting, fastflux hosting may also stress
the "unlimited bandwidth" available for downloading physically
large or highly popular files (since they're stealing someone else's
capacity, use all you want, they'll just steal more if they end up
-- unlike conventional web hosting, fastflux hosting may also stress
that they do no logging
-- participating nodes are *created surreptitiously*, and operate
without the informed consent of those who own the machines being
used, typically having been clandestinely installed via malware
-- because of the installation mechanism employed, fastflux hosting
*always* happens on consumer workstations running Windows; those
hosts will characteristically be using dynamic addresses
if the hosts under contemplation are part of a commercial web
hosting concern, for example, or are corporate PCs, by definition
we're NOT (and should NOT) be talking about them as fastflux,
because they AREN'T fastflux
-- because of the characteristically short life time of fastflux nodes,
and variability in system configuration, fastflux nodes used as web
servers do NOT have a full web hosting environment and complex
web pages or databases installed on them; rather, that sort of
thing lives on a remote back-end "master" (or set of master)
servers, and the fastflux nodes just serve as a reverse proxy to
the remote masters. This obviously exposes a vulnerability in
the fastflux paradigm -- on a well instrumented network, one can
retrospectvely review flows associated with a compromised node,
and see where the upstream/back-end master machine may be living.
nginx, while also used by legitimate web sites, is routinely used
to implement the reverse proxy mechanism
-- because the perpetrators are attempting to complicate and frustrate
investigation by law enforcement, and because some jurisdictions (such
as Germany) are perceived as offering an enhanced level of privacy
(hindering ISP malware detection and remediation efforts), perpetrators
will normally employ compromised machines from multiple international
jurisdictions; thus, a fastflux spammer targeting users in the United
States might have fastflux nodes located in Germany, France, Russia
and Romania (although any given incident will, and should be
expected to have a different assortment of machine "nationalities"
-- many fastflux domain names are heavily associated with spam; thus
fastflux domains routinely will be routinely listed on URI-based
blocklists such as the SURBL or URIBL, and the associated IPs may
be listed on blocklists such as the CBL blocklist
-- *SOME* TTL's associated with fastflux may be short, but this deserves
For example, I've seen some fastflux hosts with initial TTLs as low as
zero, and others significantly higher, but the range of 120 to 300 seconds
appears particularly relevant. There's obviously a trade off between
DNS chatter and potential associated delay, and delays associated with
a host that was formerly up now being offline or unreachable (for
-- Fastflux nameservers may be recursively fastflux in turn, but in many
cases expect to see very LONG TTLs for fastflux name servers, taking
advantage of caching and the "glue record problem."
-- Fastflux domains also differ from normal domains in HOW MANY A records
may be returned for a given IP. While most normal web hosts return
only one or perhaps two IPs, fastflux domains may return half a dozen
or a dozen dotted quads in response to a single query.
-- Fastflux domains also usually will not change IPs just for the sake of
changing. That is unlike some other services which may exploit what
effectively amounts to IP "frequency hopping" (routinely and continually
changing IPs in an effort to avoid monitoring and censorship), fastflux
nodes tend to change IPs when they HAVE to be changed (e.g., because a
formerly used node has become unresponsive or is performing poorly or
is believed to have become compromised).
-- Fastflux domains will routinely have invalid domain whois data, such
as bogus or incomplete address information
-- Fastflux domains will routinely be associated with registrars or
registration service providers who have, or who may be perceived to
have, lax or limited TOS or lax or limited abuse handling procedures
-- Fastflux A records have been seen on multiple occaisions associated
with attempts to return additional NS resource records mapping "."
to the misreants own servers on vulnerable name servers
#* fast flux hosting: employing fast flux as part of the hosting
# component of a criminal or other unauthorized activity (e.g., phishing)
I'd go so far as to say that the predominant use of fastflux is for
# * fast flux attack: an attack that uses fast flux
Are you implying that fastflux hosts are used in:
-- distributed denial of service attacks of some sort? If so, I think that
would be a good thing to illustrate with a concrete example
-- pay-per-click click fraud attacks
-- some other sort of attack?
#* short TTL: a value in the Time To Live parameter associated with a
# DNS resource record(s) that is observably less than the values
# encountered in the DNS under typical operating conditions, e.g.,
# less than 3600 seconds. Short TTLa may be used for both legitimate
# and abusive purposes; for example, the use of a short TTLa is one
# way to enable a fast flux attack.
I think you mean "one way to avoid a DDoS attack" there, didn't you?
#Using an antispam analogy, you can't conclude that an email is spam solely
#on the basis that it contains the brand name of an erectile dysfunction
#product. Ditto for short TTL.
Correct. Unfortunately there's a popular desire to have "Blackberry friendly"
sound-bite length definitions, and TTL's the thing that most people latch
onto because of its apparent simplicity.
#The use of short TTLs is one of several "markers" that you might use to
#detect an attack that employs fast flux.
#Large numbers of NS name server resource records and frequent changes to
#those RRs is another.
... but you can have FF with fully static name server RR's, too.
#The use of IP addresses that fall outside the typical address range used
#for this domain is another.
I think you're trying to get at IP address (and routing?) diversity. Some
compute inter-IP distances for observed IPs, others look at the ASNs in
use, still others look at WHERE those addresses are from (e.g., IPs from
DHCP blocks and other dynamic space).
#Evaluated in combination, these may be useful. Evaluated in isolation,
#they might result in false positives.
#We are supposed to study fast flux. Do the definitions above help us with
#the scope we are struggling to identify?
If you're willing to include the additional characteristics I mentioned
above, I think so. :-)