Possible Fix for Dynamic Querying?...and kill Spammers to boot!

Re:Possible Fix for Dynamic Querying?...and kill Spammers to boot!

> In the last twelve months, the spam problem has increased
> dramatically, and it seems to render Dynamic Querying quite
> useless. 
[...]
> Do you have any ideas how we can do something to reduce or solve
> that problem on the network level? 
> 
> Wishes, 
> Arne

--- In [email protected], "Elias Athanasopoulos" <elathan@...>
wrote:
>
> I am not arguing on how to fight spam in Gnutella; unfortunately I
> have no clue on that, I am arguing that the 'spam' problem,
> or even better: the ability to inject fake QueryHits in the system,
> is a *real* and *serious* problem. 

The only place I see to tackle this problem is at the UltraPeer level.

They are the only ones that can tell if a connected node (especially a
leaf) is replying to a ridiculous number of queries. If a node is
responding to EVERY query (especially if it has 10+ Alt-Locs with
each!) then that node can be considered too "noisy" and no (or very
few) requests should be sent to it.

If a questionable Leaf or UltraPeer's hash query table sent to a
"good" UltraPeer is too full (as it might be with a spammer that
replies to everything), then at the very least that questionable Leaf
or UltraPeer should always be the last resort to send query searches
to. A leaf that's sharing too much is unlikely to have free upload
bandwidth anyway, so trying other leaves first makes good sense. This
might also decrease the probability that the majority of real file
hits of a search come from very few sources...as well as decrease
"early" spam hits from leaves on the same UltraPeer as the searcher.

Also, overfilled leaf hash query tables should not be used by a
UltraPeer to create the hash query tables passed on to other
UltraPeers. This might slowly reduce the masking of spammers by
neighboring innocent UltraPeers...as well as reduce the UP-to-UP traffic.

I've heard rumors that many spam nodes are claiming to be UltraPeers
but are actually without leaves...thus much like old Gnutella v0.4
Peers. They seek 100's of connections into the network to
short-circuit query routes and to guarentee they "hear" almost every
search sent out. This may be what puts such a heavy strain on so many
host caches. Perhaps UP-to-UP search queries could cycle through
connected UltraPeers to send to -- to hopefully not always hit the
"bad ones" first. Also, a possible way to cross-check them is to see
how they handle push routes through themselves or UDP Nat
hole-punching. Maybe some criteria can be built up just from what a
single UltraPeer can see to determine which neighboring UltraPeers are
Pure Spammers(tm)?

Much of this is already implemented in Gnutella v0.6 since I last
researched it, however some of it was optional.

Maybe UltraPeers could do a quick spammer spot-test?: randomly
generate 8 characters (with or without vowels for twice the fun) and
send that as a search query to every newly connected UltraPeer or
Leaf. It's highly likely that anything that replies to that search
query is a spammer. This would only be a stop-gap measure to eliminate
spammers, as they will likely adopt smarter reply strategies were this
test commonplace.

Spammers generating UDP out of bounds query replies would be much
harder to catch, since the UltraPeers they're connected to would not
see any of their replies. If their hash query table is kept small (but
matches the most common search words), then it may be impossible to
detect them but they probably wouldn't be flooding the system as bad
as we've seen. Unfortunately, thanks to UDP OOB traffic, their ip
couldn't be detected by whoever sent out the search request in the
first place even with a packet monitoring program...so they'd be
nearly invisible. Against them, only a modified spammer spot-test
might work...and it would likely generate false positives. (calling a
leaf/UP a spammer when it is not) But that's the best idea I can think of.

The best defense against spammers is not to ban-block them but to
connect to them and reply almost nothing to them.
"ping pong"!