Re: [gnso-ff-pdp-may08] Fast Flux Definition - V4.1

[Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>]

#LoL, interesting qualifier!
#
#Do you mean "terribly unhappy" as in "terribly unhappy living with Cindy 
#Crawford" or "terribly unhappy living with Roseanne Barr"?

I'd think more along the lines of "living with a pair of shoes that are
generally quite servicable and which fit pretty well, but which can
rub in one spot just a little if you wear them for a really long walk"

For example, if I were in a cut-some-molefoam sort of mood, I might dig 
in on the "changes its topology" language in Dave's definition.
For me, topology is more about command and control communication 
architectures than about instantiation.

The fastflux networks I've looked at run on periodically changing 
compromised nodes (e.g., the network will be on different hosts from time 
to time) but I wouldn't call that a change in topology. I don't see, for 
example, a change from a hypothetical star topology to a linear topology,
or to a ring topology, or to a doubly-linked star topology, say. 

Or consider "(rapid) modification of TTLs for name servers and 
malicious content hosts" -- most of the fastflux networks I see
have *short* TTLs, but the TTLs themselves don't actually change --
thus, I don't see example.com returning a TTL of 120 now, and a
TTL of 7200 later -- if it is 120 now, it will be 120 later, too,
(modulo cached value TTLs decrementing the way they should, of
course)

Those are the sort of rough edges that I might be tempted to buff
out/foam over if we were going to go for a long walk with that
definition. 

Beyond those wordsmithing issues...

I was also intrigued to see "monitoring to determine/conclude that 
a host has been identified and shutdown." That's an intriguing bit
that I haven't heard publicly discussed much. One might consider
monitoring to be something as crude as periodically trying to 
retrieve a fast flux web page from a specific compromised host -- 
if that page retrieval fails, well, then you'd know that there's
something up with that node, and a replacement should be substituted
into the rotation. But that sort of active polling actually isn't
required -- if we assume that fastflux front end hosts reverse 
proxy traffic to a backend host, the backend host can keep track
of the front end hosts from which it sees (or doesn't see) traffic,
and adjust things accordingly if things look "unusual."

There's also the distinctly non-zero possibility that one (or more)
of the fastflux IPs returned for a fastflux domain name may not be
like the others. Sort of "duck, duck, duck, duck, duck, duck, duck,
duck, goose," if you get my drift, where the goose might be a host
directly under the control of the spammer, with accordingly good
instrumentation of what it sees (but this is obviously speculative)

Monitoring (and fastflux operator reaction to monitoring) is a 
fascinating topic since the sheer act of monitoring may provide
a way to identify participating nodes, or to disrupt operation of
the fastflux network (trivial example: imagine blocking access to
a fastflux network node, EXCEPT in the case of an identified 
monitoring agent, which continues to be given unfettered access, 
thereby leading it to an erroneous conclusion w.r.t. the usability 
of that node).

Regards,

Joe

Disclaimer: all opinions strictly my own.