RE: [gnso-ff-pdp-may08] The need for facts

["Mike O'Connor" <mike@xxxxxxxxxx>]

At 04:13 PM 7/13/2008, Joe St Sauver wrote:

> Hi!
ah.  thanks for humoring me...

David, i'm kinda responding to your note as well, so you may want to 
read along...

> #1) what facts would we need in order to understand its scale and scope?
>
> 1a. How many IP addresses are known to be participating as fastflux nodes?
> 1b. How many domains names use fastflux?
> 1c. How many unique name servers support fastflux domains?
> 1d. What fraction of those unique name servers are themselves served on
>     fastflux IPs?
> 1e. What registrars or registration service providers have been used to
>     create fastflux domains?

i like these first four -- they seem to be crucial to understanding 
what we're dealing with.  in order to make the data easier to collect 
(i'm starting to get the glimmer of an idea), let's rephrase just a bit.
- let's assume we've recruited some partners (some ISPs, some 
registries, some registrars, some really big data-center shops -- 
people with Big Routers and Lots of Traffic).  a purely voluntary 
effort, not something laid down in policy.
- let's further assume that we've hammered out a methodology, and 
maybe even some code, for our partners to use.  shared tools, that 
return consistent data no matter who deploys them.  hm.  open 
source...  etc. etc...
- let's stay away from tinkering with protocols (WHOIS, DNS, etc.) if 
we can -- mostly because that's Too Hard, at this stage in the game.
so. we deploy our toolset and our partners use those tools to gather 
data -- and here comes the rewording...
1a. How many IP addresses do you see that are known to be 
participating as fastflux nodes?
1b. How many domain names do you see using fastflux?
1c. How many unique name servers do you see supporting fastflux domains?
1d. What fraction of those unique name servers that you see are 
themselves served on
    fastflux IPs?
1e. What registrars or registration service providers have been used to
    create fastflux domains that you can see?

this is the kind of question that (if i still owned my ISP -- 
gofast.net) i'd throw at Ralph and Marv and see if they could write 
some cool code that we could just run locally, maybe on the router, 
maybe on some kinda packet-inspection box close to the router, i don't know.
it probably wouldn't take long to come up with a pretty good set of 
statistics that would at least approximate how bad this problem is...

> 1f. If notified that a customer's domain is fast fluxing, what (if anything)
>     will a registrar or registration service provider do? How long does it
>     take them to do it? If they do nothing, why? If they *do* do something,
>     what do they do?
> 1g. If notification is made to ISPs, will they pass those notifications
>     along to the infected customers? If so, do the customers, once notified,
>     appear to be remediated (or at least cease to be seen as fastflux nodes?)
these last two don't excite me as much.  partly because we're 
tiptoeing into a tech/policy "solution" again, and partly because 
this data would be much much harder to collect.  so i'd leave these for now.

> #2) where could we get those facts?
>
> 2a. Accept a feed of fastflux domain name candidates, and verify the IP
>     addresses on which they live.
i like...

> 2b. From the 2a list, extract name servers and registrars/registration
>     service providers
i like...

> 2c. Contact the registrar/registration service provider with the observed
>     data, and note their response (including the time required to make
>     those reports, and the time required for the registrar/registration
>     service provider to respond/react). Truncating the right tail of the
>     response window at some reasonable time period may be desirable.
not so keen on this one -- same reason as a minute ago.  we're 
getting outside the bounds of a "passive" monitoring approach and into policy.
> 2d. Track individual fastflux IP's over time,
i like...

>  including noting time of
>     ISP notification.
not so much, see above...


> #3) are the statistics being collected now? how well -- is the data credible?
>
> 3. I'm a big believer of data replication and validation. I'd encourage folks
>    who feel likewise to participate in measuring this phenomena. Replication
>    brings validity and trust.
right!   that's why i like my notion of building a set of tools so 
that anybody with a lot of traffic could help out.

> #4) if they're being collected, is the person/organization willing to
> #share them?
>
> 4. In the "everyone a gardner/hunter, everyone a chef" model, that's up
>    to each gardner/hunter chef. :-)
could be -- what i was getting at here is that somebody may already 
be making a business out of collecting some of the data we need, and 
might not want to give it up without payment.  or at all.  there's a 
lot of proprietary stuff out there these days...

> #5) if they're not being collected now, what's the best place to get
> #them and is it worth it to go after them?
>
> WRT to the "is it worth it to go after them," Am I detecting backsliding
> from the earlier "we like facts/data?" :-;
no, although i'm a notorious backslider.  in this case, what i'm 
getting at is the notion of data cost.  sometimes we may need to 
trade off the value of the information against the cost of 
acquiring/processing it.

> Data collection isn't completely painless, but it doesn't need to be
> particularly painFUL, either.
right.


> #at this stage of the game, i'm yearning more for reliable information
> #*sources* than raw data.
>
> Be paranoid. Trust no one. A thousand eyes are better than one (or even
> two :-) ). Information you collect yourself is the best information of all.
a lot of my security geek friends would lean into that 
statement.  for example, the only encryption algorithms that they 
trust are the ones that are public, so that they can be 
peer-reviewed.  i have a feeling that our data-needs are 
similar.  i'm more trusting of "open" data than "proprietary" data in 
this area.

> #reliable/public/published methods of analyzing that data to help us
> #understand the breadth and depth of the problems we're looking at.
>
> The nice thing about fastflux is that it is "self-exposing" once you
> know where to look. Happy to start suggesting relevant rocks.
let's start building tools to let lots of folks look under those rocks...

which raises another one of Dave's points -- we need to make sure 
that we don't accidently create unintended consequences (where 
bad-actors move on to other exploits) with our data-gathering.  so 
another design-criteria would be to make these "watching" tools as 
nimble as possible so that they could be quickly updated to "watch" 
for new exploits.

> #one of the things that i'm pondering is the need for some sort of
> #collaboration between us (ICANN) and some of the other institutions
> #that are out there.
>
> Collaboration is very good, as is your list. At the risk of stating the
> obvious, I'd also suggest the APWG be formally on that list, and MAAWG.
doh!  sorry about that.  of course.


> The Educause Security Task Force is actually the Educause/Internet2
> (or Internet2/Educause) Security Task force, and that's yet another
> activity I'm involved with as part of my $DAYJOB. :-)
>
> #sorry about the US-centric list, this is just a list that comes to
> #mind, left over from the days when i worked for a living.
>
> Terena is one technically oriented possibility from Europe.
>
> Since we're talking about cybercrime, I also wonder about law
> enforcement agencies, such as Interpol.
>
> Would vendors also provide a useful source of data?
yea verily.  Cisco is very active on SSAC, would probably be a great 
candidate...

> #thanks Joe for the speedy reply, even though it did sorta make my
> #eyeballs peel.  :-)
>
> De nada. :-) Happy to peel eyeballs anytime. :-)
great comeback.   thanks guys.  enjoy the rest of this beautiful 
Sunday -- we're having incredibly wonderful weather here at the farm.
m


> Regards,
>
> Joe
>
> Disclaimer: all opinions strictly my own.