WinMX Floods!! Do your part to help free up the network!

[Widdle]

WinMX is low-key on the money-grubbers radar, but it is being attacked. Lately a flood of DHCP clients have been cramming the network with secondary connections and also jamming shares full of fakes. It does seem that there is a very simple way to combat this. If you are a Primary connection, run PeerGuardian or some comparable IP blocker and you will see your Secondary connection port pinged constantly by Anti-P2P IP's. Since they are apparently using known servers to load up the network (they are being very successful, just watch and see how fast your Secondary spots fill up after a Primary connection is made) the software is blocking them. Just watch your "Blocked IP" log fill up after you start running MX on primary. This is no permanent fix, but perhaps if we can create a buzz then enough Primary users will start doing this and maybe unload the network a little. Or at least kill enough to make certain searches within the MX environment useful again. What do you guys think??

[tm,]

What do you guys think??

Does Kevin Hearn know about this? And if so, will there soon be a WinMX update to plug that exploit?

[Widdle]

I assume he knows, but as of now, it's a start.

[Dazzle]

This is something that we have been advising folks to do for a while now

http://www.slyck.com/forums/viewtopic.php?t=9448

You are able to see the denial of service attacks occuring quite easily with peer guardian.

My annoyance is this, even if we block all the anti p2p servers, if they can bring enough to bear down on you, you will suffer from socket overload and still be knocked off the network, but it has helped the situation as far as I am concerned.

[sumfuka]

You are able to see the denial of service attacks occuring quite easily with peer guardian.

My annoyance is this, even if we block all the anti p2p servers, if they can bring enough to bear down on you, you will suffer from socket overload and still be knocked off the network.

What "denial of service attacks" though? You mean the media company's companies trying to connect into your primary WinMX client? Or do you mean the flood of incoming search results seen all-too-often as a result of legitimate network primaries flooding connections due to the effectivness of the media company's companies systems at hooking themselves onto unsuspecting primaries?

Also, you can't "block all the anti p2p servers", as it where, as it ain't the "anti p2p" clients doing the damage: it's legitimate primary users. The only possibility, as I see it, would be to get every primary user on the network to run blocklists that are actually effective (forget PeerGuardian, because I doubt very much that it could block effectively without heavy collateral damage).

[sumfuka]

P.S. Hey, if you do want to block fairly effectively, block this:

Bellsouth Ranges;
~~~~~~~~~~~~~~~~~
65.0.0.0 - 65.15.255.255
65.80.0.0 - 65.83.255.255
66.20.0.0 - 66.21.255.255
66.156.0.0 - 66.157.255.255
67.32.0.0 - 67.36.1.255
68.16.0.0 - 68.19.255.255
68.152.0.0 - 68.160.31.255
68.208.0.0 - 68.223.255.255

Covad Ranges;
~~~~~~~~~~~~~~~~~~~~~~~~~~
64.105.0.0 - 64.105.255.255
66.134.0.0 - 66.134.255.255
66.166.0.0 - 66.167.255.255
67.100.0.0 - 67.103.255.255
68.164.0.0 - 68.167.255.255

BT Openworld Ranges;
~~~~~~~~~~~~~~~~~~~~
81.128.0.0 - 81.159.255.255

Tiscali UK Ranges;
~~~~~~~~~~~~~~~~~~
80.40.0.0 - 80.47.255.255
80.225.0.0 - 80.225.255.255
212.139.0.0 - 212.139.255.255

PacBell Ranges;
~~~~~~~~~~~~~~~
64.160.0.0 - 64.175.255.255
67.112.0.0 - 67.127.255.255
68.120.0.0 - 68.127.255.255

DSL.net Ranges;
~~~~~~~~~~~~~~~
64.51.0.0 - 64.51.255.255
64.144.0.0 - 64.145.255.255
64.204.0.0 - 64.205.255.255
64.248.0.0 - 64.249.255.255
65.84.0.0 - 65.86.255.255
66.95.0.0 - 66.95.255.255
66.200.0.0 - 66.200.255.255

Singnet Ranges;
~~~~~~~~~~~~~~~
220.255.0.0 - 220.255.255.255

Statics;
~~~~~~~~
38.113.214.*
38.119.64.*
72.35.224.*
209.11.134.*
212.71.252.*
213.219.9.*
204.193.136.*

[Califax]

I use bellsouth...

[Widdle]

What "denial of service attacks" though? You mean the media company's companies trying to connect into your primary WinMX client? Or do you mean the flood of incoming search results seen all-too-often as a result of legitimate network primaries flooding connections due to the effectivness of the media company's companies systems at hooking themselves onto unsuspecting primaries?

When a primary is connected, it can only handle service to a few secondaries (12 at default). If the media companies use servers to connect to hundreds of Primaries all of the time, it makes acquiring a secondary connection very difficult for other users, as well as allowing them to flood search results. I have seen, using an IP blocker, a ton of attacks on the open ports that WinMX uses for connecting Secondaries. For the first time since I can remember, my Primary is not loaded with twelve secondaries immediatly after connecting. Now I frequently have excess capacity.[/quote]

[sumfuka]

When a primary is connected, it can only handle service to a few secondaries (12 at default).

Well, I wouldn't say "it can only handle", it's just that, at the default settings for a primary connection (7 KB/s OUT / 10.5 KB/s IN), it defaults to a maximum of 12 slots for secondary connections. I don't see this limitation being an issue so much, though, because secondary connections to a primary client only use a negliable amount of resources normally (when the effects of the media companies, and shitty third-party wares, are removed).

If the media companies use servers to connect to hundreds of Primaries all of the time, it makes acquiring a secondary connection very difficult for other users, as well as allowing them to flood search results.

Yeah, possibly, though I do wonder at just what the average ratio between primaries & secondaries might actually be, as it's not uncommon for the primary connection I operate here to run for a reasonable period of time with less than 9 secondaries attached (which means it's advertising free slots for secondary connections to the caches) after blocking out the media companies)). I guess that could be down to some allocation problems the cache might be seeing (the cache allocating secondaries to primaries with free slots), though I haven't noticed any difficulty here in being able to source a primary connection when configured as a secondary. It'd usually connect within a short period of time (within 10 seconds).

With regards "hundreds of primaries all the time": I think that should probably be many thousands, or as good as all primaries on the network that have nothing preventing the media comapnies from connecting to them (sorry, but PeerGuardian will not stop them, though it will help by a very small amount (because it does block some of the statics at least)).

I have seen, using an IP blocker, a ton of attacks on the open ports that WinMX uses for connecting Secondaries.

What do you classify as "attacks"? Surely you just mean that the "IP blocker" software that you're running has merely indicated attempts from blocked IPs to connect into your primary? That's about as much as I'd expect to see, as the media company's companies clients seek out (by querying the peer caches) primary users advertising free slots (to the peer caches) for hosting secondaries, and repeatedly attempt to connect to them.

I wouldn't exactly call that an attack.

For the first time since I can remember, my Primary is not loaded with twelve secondaries immediatly after connecting. Now I frequently have excess capacity.

Yeah, I sometimes see that here, too. I do believe it's true that if you do operate a primary connection without any IP blocks that the media company's companies will probably consume quite a few secondary slots, and quite possibly the majority of those slots after a period of time, as they do appear to aggressively seek out new primaries to connect into.

But then again, maybe the network population is reducing as the media companies achieve their desired effect: at preventing the masses from downloading their wares for free. Look at what happened/is happening to FastTrack...

I wonder at just how many hits on the peer caches these clients must running up as they continuously seek primaries, that is, if they even use the FC caches? I tend to believe that they do, and if you believe that, then you have to ask the question 'well why not block them from hitting the cache so frequently?'. Because FC's hands are tied?

---

Change the encryption method/protocol, network protocol, and/or network topology (any or all of these) and I suspect you'd suddenly see many of the current problems completely disappear.

Maybe easier said than done, though...

[sumfuka]

I use bellsouth...

Yeah, that's my point...

[Widdle]

Sumfuka,

You obviously have more knowledge than I when it comes to this issue, thanks for the technical input. I just started this thread because I know that alot of Primary users on the WinMX network have no idea that the crap searches coming in are coming from their connection and others like it. Alot of users have no knowledge of how the network works at all, and they are getting slammed by the media companies connection attempts.

Since you have more technical ability than I, would you mind letting me know if there are other strategies that could be employed to help deal with this problem?

Also, is it possible to write software that can detect these types of fake files automatically? If so, can it also get the IP of the sharer and log it so it can be uploaded to block lists? I was thinking that if several primaries ran this software with their extra BW perhaps we could coordinate block lists.

Thanks for the help.

[sumfuka]

Sumfuka,

You obviously have more knowledge than I when it comes to this issue, thanks for the technical input.

Thanks, I'm just trying to be constructive (although maybe challenging).

I just started this thread because I know that alot of Primary users on the WinMX network have no idea that the crap searches coming in are coming from their connection and others like it. Alot of users have no knowledge of how the network works at all, and they are getting slammed by the media companies connection attempts.

Indeed.

Since you have more technical ability than I, would you mind letting me know if there are other strategies that could be employed to help deal with this problem?

Well I don't know much really. I do have some suggestions & a few ideas, though, for helping cope with some of the problems.

One simple thing a user can do to reduce (or even eliminate) fakes being listed in their search results is to add "-my" before any search they make, e.g:

Code: Select all

-my filenamehere

This just filters the word "my" from any results returned, which filters the full file-paths that the fakers commonly use:

C:\My Music\
C:\My Shared Folder\
C:\Documents and Settings\Username\My Music\

This will also filter out a lot of legitimate results but shouldn't be much of a problem if the file you're looking for is highly popular in the first place.

Note that the fakers could easily put a stop to this if they wanted to.

Also, is it possible to write software that can detect these types of fake files automatically? If so, can it also get the IP of the sharer and log it so it can be uploaded to block lists? I was thinking that if several primaries ran this software with their extra BW perhaps we could coordinate block lists.

I have some ideas to take care of this, but don't know how technically feasible they might be to produce in reality. I don't really want to type those ideas up here though.

(but here's one... )
I've an idea for an app/plugin that would block fakers dynamically according to the frequency of their attempts at connection for being hosted (over a period of a day, or days). Blocklists could potentially dynamically generate (and degenerate) themselves over a short time period quite easily, I think, as the fakers don't actually operate from that many IP addresses (maybe only around 20 operating on the WPN at any given time), but those few addresses do attempt to connect very frequently (totally unlike a legitimate user that may only ever try to connect to a specific primary user once in every blue moon) in comparison to legitimate users.

Saying this, though, it wouldn't reduce the number of fakes on the network seen by hardly anything until at least a large number of users operating primary connections used it, so it could well prove ineffectual overall.

There's also some other crazy ideas, too, though it's prolly best I don't go there...

Regarding the detection of fake files themselves, I don't have any ideas about how that could be done easily.

Thanks for the help.

Just trying to contribute something here. Thanks.

[Widdle]

Thanks alot, it's nice to see someone else who's concerned about keeping/making WinMX a clean network. Hopefully the next version (whenever that will be) will update the protocol or something to make this less of an issue.