RE: [gnso-ff-pdp-may08] The need for facts
- To: gnso-ff-pdp-May08@xxxxxxxxx
- Subject: RE: [gnso-ff-pdp-may08] The need for facts
- From: "Mike O'Connor" <mike@xxxxxxxxxx>
- Date: Sun, 13 Jul 2008 17:09:38 -0500
At 04:13 PM 7/13/2008, Joe St Sauver wrote:
ah. thanks for humoring me...
David, i'm kinda responding to your note as well, so you may want to
#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
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
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.
2b. From the 2a list, extract name servers and registrars/registration
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,
including noting time of
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
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
Data collection isn't completely painless, but it doesn't need to be
particularly painFUL, either.
#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
#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
#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.
Disclaimer: all opinions strictly my own.