Idea for detecting fakers

[plasticfork]

K, an idea for detecting fakers;  :twisted:

Modify a chat server client so that it periodically 'advertises' free slots for hosting secondaries when hooked into the network.  The client will then receive incoming secondaries looking for a primary host.  The client stores the addresses of the incoming secondaries though does not accept them, rather it just closes the connection to send them on their way elsewhere.

The modified chat server client sends a packet of data to a 'central database' containing the IP of the secondary client that attempted connection.  The 'database' logs the IP of the sender and the IP of the connecting secondary contained within the packet (...and any other useful info like: Time, Date).

Multiple people run these modified chat servers (of course it's no longer a chat server, just a dummy primary of sorts), let's say 5 users.  If 3 or more of those 5 users clients respond with the same IP address attempting connection then the IP gets added to the WMW blocklist for 'a while'.

If the 'modified chat server' could be made to use KM's Winsock DLL, then as the DLL 'becomes aware' of the newly blocked addresses (as retrieved from the WMW blocklist) it'll prevent the fakers from reaching the 'modified chat server' so it'll no longer respond with IPs already blocked.  Alternatively, if the modified chat server doesn't use the DLL, it'll frequently respond with the addresses of fakers that are already on the blocklist which could be useful as a method of determining when faker IP addresses become inactive (e.g. if a faker address that's already on the blocklist hasn't been reported for X number of days, then clear the entry from the blocklist).

*Salt to taste.* 

[..Ñøßߥ..]

ive read that three times and im still lost, anyone help me out here?

[Bearded Blunder]

The very fact it refers to the WMW blocklist renders it useless for detecting flooders, because that list requires you've already detected them.. it's totally redundant.... or at least, that's how it reads to me....

[plasticfork]

ive read that three times and im still lost, anyone help me out here?

Sure, which part(s) don't you understand?  I'll do my best to expand what I mean... 

The very fact it refers to the WMW blocklist renders it useless for detecting flooders, because that list requires you've already detected them.. it's totally redundant.... or at least, that's how it reads to me....

You don't seem to understand.  The 'system' is one where detection and addition of entries for the WMW (actually I mean WMG here, though they're both (or where) the same thing) blocklist is somewhat automated in comparisson to what's required to maintain the list manually.

[KM]

the basis for the idea (although badly thought out implementation) is quite simple, and something i had considered doing but not implemented in anything yet due to the fact that i couldn't guarantee it's accuracy although i was actually considering testing by just logging flooders for manual testing just to see how effective it would be - was waiting for ghostship and me_here to come back before doing that though

for those who didn't understand it the basic idea is simple:
run multiple primaries to get flooders to try connecting, and make a note of which IP Addresses tried connecting to that primary and which didn't (for that purpose simply logging inbound connections to live primaries would be effective), if the same IP Address attempts to connect to multiple primaries then it is a flooder - as the flooders will connect to many primaries whereas legitimate users would only connect to a single primary

[..Ñøßߥ..]

for those who didn't understand it the basic idea is simple:
run multiple primaries to get flooders to try connecting, and make a note of which IP Addresses tried connecting to that primary and which didn't (for that purpose simply logging inbound connections to live primaries would be effective), if the same IP Address attempts to connect to multiple primaries then it is a flooder - as the flooders will connect to many primaries whereas legitimate users would only connect to a single primary

With ya now.

[Bearded Blunder]

Thanks KM, that clarified it totally, yes I see what's being suggested to attempt now

[plasticfork]

My thoughts about modifying a chat server into a dummy primary of sorts is that such a thing could be made to run very quietly on a user's system (those involved), being able to limit bandwidth consumption down very low (like 1 KB/s - thinking about NACS there ), and maybe specify P=16 or something for increased "I've got free secondary slots" broadcast power to draw Smokey. A client like this, advertising free slots constantly, would keep the Smokeblower systems knocking constantly.  This way if there were only a handful of these clients operating I think the chances would be high that a multiple of these clients would pick up identical addresses knocking, yet the chances of a legit secondary user hitting multiples would probably be pretty damn slim... in theory anyway.

[KM]

the reason for doing it on a normal real primary user is because we're not sure how they are locating primaries, simply running a program listening for connections won't make them magically find it, there are several ways they could be locating them so simply running an actual winmx on primary is the only way we can know for sure they will locate it

[plasticfork]

Well, it's quite simple, IMO.  They have clients hooked into the WPN that look for primary clients with a free secondary slots count above 0 in the WPNP chatter, like search queries, etc.  As soon as they detect a primary advertising >0 free sc slots they attempt to hook into that user.

If you used an official WinMX client, running standard, you'll run into the problem where the free SC slots reach zero and therefore Smokeblower ignores it (no point attempting to initiate connection into a primary with no free SC slots).  As I'm sure you know, the default setting for WinMX primary client secondary slots is bound from 9-12 (at 7 / 10.5 KB/s allocated bandwidth).  When the client establishes 9 secondaries it ceases to advertise free SC slots in search query/channel listing/etc packets (the '9' number decrements to 0) leaving 3 as headroom to accomodate clients that call even after it's stopped advertising.  A standard WinMX client will not advertise as having slots free for hosting secondaries if it already has between 9-12 (at default setting as mentioned) secondaries attached (this is going from memory somewhat but should be generally correct info ).

If you instead used a modified chat server client, with the ability to broadcast dummy search queries (or similar) into the WPN (via its attached primaries of course), then you have the ability to hard set the '9-12' SC slots limit (the '9' being important here) so that it remains static above zero.  This way the client will always draw secondaries to the client looking for connection, and most importantly, Smokeblower clients, so long as it periodically sends packets out into the WPN that contain the free SC status.

Hey give it a go or something.  Run a standard WinMX client and POKE the memory to change the '9' of '9 & 12' to something greater than 12, e.g. 16-12.  This way when the client reaches the SC hosts limit of twelve it'll still actually advertise as having 4 free SC slots to the network, so it'll continue to receive secondaries knocking constantly.

Anyway m8, I know you're well knowledgable about the WPNP and I don't mean to come across as condesending or anything here, nor will I state it all as absolute fact, though I think you'll see where I'm coming from if you have a play about sometime.

Just offering an idea for the blocklist maintainers so HTH.

[SamSeeSam]

One question... What if a person is running multiple computers through the same router? Does it mean that all of them have the same IP? If so, won't this method affect them?

[GnarlySnarly]

what about privacy issues.

how does building and logging a centralized list of IPs trying to connect to WPN affect user privacy and anonymity?

[Me Here]

Samseesam,

When we say multiple connections its quite possible that those numbers would reach the 100s+ amounts of connection attempts. But yes in theory that could possibly effect things.  This is why human intervention is needed, and I for one have not heard an idea for automation that is 100%.  Until there is one that is as accurate as birth control ie: 99.9% :roll:  the list will be humanated instead of automated..

As for privacy issues Gnarly, you will notice that its not explained how the list's numbers are found, maintained in detail.  As of now the system in place depends on a small group of highly scrutinized highly trusted folks hand picked by me.  Now I hear what your thinking, but its got to be done by someone and trusting them is something I have asked for blindly and its proven to be working.  The above system would be no more privacy invading then what is already in place.

As I said..it doesnt sound 99.9% effective and fool proof as yet..but it does sound familiar ..

[SamSeeSam]

So what is wrong with this? Is it that it won't be effective as we don't know how they search for primaries like Km has said? You must be knowing some of them. Perhaps this could be tried out as an experiment? If it is very effective, then we could use it...
If not, back to square one

[KM]

the reason for not automating it is because in theory a real user could get caught by it - however unlikely it is, for example if we had 4 primaries monitoring connections and someone happened to use 5 copies of MX on 1 IP and 4 of them connected to the monitoring primaries then it would get a false hit... in reality the chances of that happening are so small it's barely worth considering, however the only way to do it with no chance of false results is with a lot more than a few primaries

for now the various ways used to catch flooders all seem to agree with each other and manually verifying things works "quick enough", for now...

[SamSeeSam]

5 OK very less. I was thinking on the order of say a hundred or so... You can find the volunteers for that I can assure you that

[KM]

Don't worry, we have things under control for now, and if anything else is required then it can be done

[SamSeeSam]

You are the boss

[plasticfork]

Well hello again.  "In theory"... gee, the chances of a single legitimate user hitting upon multiple primaries (actually clients modified to monitor connections) would probably be highly unlikely.  And, of course, if one was to look into a system like this I would think that one would do enough testing prior to full-time implementation to be sure that it was acting as it should do.

I personally stand to gain or lose nothing whether something like this should ever be created, but, having (I think) a reasonable understanding of what work is involved in maintaining the list manually my interest was only to put forth an idea for making those folks lives easier.

I challenge you to log a single secondary user call upon 4 (low number - increase for even less chance) unique primaries for hosting that isn't a faker. 

There are other ways to do this, too, without such a requirement for multiple users to run modified clients.  A client could also be set to watch for addresses that knock the TCP port greater than n number of times.  You'll find fakers act somewhat differently to your average Joe by the frequency of their connection attempts.

Lurker (hi).

[KM]

rabbit connects to 5 primaries for a minute or two to load the channel list, and of course someone could have 4 computers running winmx - also caches running ranmas cache software apparently maintain secondary connections to 16 primary users... but a sample of a few hundred primaries would be more than enough to easily spot flooders, and watching it for a few days before it goes live would allow configuring it to take in to account things like that

monitoring for multiple connections can be of use in some cases, however it is not very reliable, for example during a 1 hour period monitoring my own primary i noticed the flooder that connected the most tried over 300 times, yet there was another flooder that only attempted to connect once, with numbers of attempts between the 2 extremes

there are 2 approaches (neither used currently) that could be used for reliable flooder detection, firstly checking the connections to several hundred primaries (no reason for any legitimate system to connect to more than 20 or 30), or there is also the idea of having a primary that receives the shared files list from the client, then checks that for flooders - that way a single connection to any monitoring system would identify them as a flooder (wouldn't need to be a full primary, as it could send real users off to somewhere else after confirming them as OK)