ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


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

RE: [gnso-ff-pdp-may08] Re: Mannheim score concerns (minority view)

  • To: fastflux@xxxxxxxx
  • Subject: RE: [gnso-ff-pdp-may08] Re: Mannheim score concerns (minority view)
  • From: Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>
  • Date: Wed, 17 Sep 2008 11:10:53 -0700

#On Wed, Sep 17, 2008 at 12:23 PM, George Kirikos wrote:
#> In particular, just as malevolent virus authors ("the bad guys") today
#> purchase anti-virus software to pre-test their creations against the
#> fast flux techniques can certainly test their networks to see whether
#> signatures provided by anti-virus vendors, malevolent agents using
#> their score is at an "acceptable" level. In other words, they'll
#> adapt. Thus, the formula begins to lose its power to discriminate
#
#I just wanted to add that the notions of adaptation over time and
#pre-testing aren't confined just to anti-virus systems, but also in
#the email spam and web-spam worlds, to give further examples. Email
#providers and search engines are constantly tweaking their
#algorithms/formulas as spammers adapt to existing ones. A static
#formula is likely doomed to failure.

I'm not sure the sort of evolution you fear will happen in the case 
of the Mannheim formula. Remember that it is a very simple formula,
and essentially only tracks/penalizes two things:

-- the number of IPs mapped to a given IP address over time
-- the number of ASNs to which those IPs map

and it would be hard to "game."

If you use a bunch of IPs from many different ASNs, you'll get a high
score; if you use a single IP (or a small number of IPs) from a 
single ASN (or a small number of ASNs), you'll get a low score. 

Any spammer (and any non-spammer!) would have to use at least one IP 
(and associated ASN), or their FQDN wouldn't resolve.

If they try to flux just within a single ASN, to avoid being
penalized for having diverse ASNs, they lose survivability (one
abuse guy "skating well" as my French Canadian friends might say
could "clear the ice" in a single fell swoop, to the dismay of
the bad guy/bad gal). 

If the miscreants use multiple ASNs, but just rotate through a 
small fixed set of IPs, antispammers can and will hunt and kill 
that complete small set on an IP by IP basis.

I think that the best that bad guys could do would be to try to
operate "just under" the current threshold score, however:

(a) as the Mannheim paper's authors mention themselves, the 
threshold value *or potentially even the coefficients of the 
linear equation may need to evolve over time, although right 
now it seems to do a very good job of identifying known fast 
flux hosts) and

(b) anti-spammer pressure will make it hard for the spammers 
to persistently inhabit that narrow tenuous zone (remember, 
we're talking botted consumer hosts, so systems get identified 
and cleaned or taken off the air, so hosting stability will 
likely be hard for spammers to achieve). 

I want to also touch on the apparent concern that the 
Mannheim formula would somehow become the one-and-only fastflux 
detection test blessed for the eons. 

Malicious online activity, including fast flux, is like a 
disease in medical or veterinary contexts.

A simple test might identify a condition today, but tomorrow
we might have a better, more sensitive, quicker, cheaper, 
test. So be it; try and adopt the better test as it becomes
available. But in the mean time, the X-ray/throat-swab/MRI/
blood pressure cuff we've got available does a good job of
at least identifying some "illness" until a better test
can be identified and routinely becomes available.

Finally, remember that the Mannheim formula identifies sites 
that ARE fast flux, it does NOT identify sites that AREN'T 
fast flux. 

It's sort of like a sieve in that respect: if you don't initially 
get caught by its generously sized mesh, another sieve with a 
finer/different test can always be interposed beneath the first 
test for a second more sensitive attempt.

Regards,

Joe



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

Privacy Policy | Terms of Service | Cookies Policy