Posted by anthonyberet on 09/08/05 18:16

Billy Joe wrote:
> anthonyberet wrote:
>
>>Billy Joe wrote:
>>
>>>FeMaster wrote:
>>>
>>>
>>>>"Don M." <newsreader@nospam4fineartsnospam.com> wrote in message
>>>>news:GN6dnWT7p9ZmHoPeRVnyrQ@giganews.com...
>>>>
>>>>
>>>>>Thanks for the heads up. Maybe we could get Tony daHat to update
>>>>>the list on his page
>>>>>http://www.geocities.com/anthony_beret/winmxfakefiles.html
>>>>>
>>>>>IP ranges to be blocked, especially by primaries:
>>>>>
>>>>>63.216.0.0-63.223.255.255 //NetSentry
>>>>>
>>>>>(following list was compiled by db)
>>>>>38.113.214.0-38.113.214.255 //PSI
>>>>>38.119.64.0-38.119.64.255 //PSI
>>>>>72.35.224.0-72.35.224.255 //Fuzion
>>>>>204.9.116.0-204.9.119.255 //Fuzion
>>>>>204.193.136.48-204.193.136.63 //SmokeBlower
>>>>>204.193.136.96-204.193.136.127 //SmokeBlower
>>>>>209.10.143.64-209.10.143.95 //Macrovision
>>>>>209.11.134.0-209.11.134.255 //Globix
>>>>>209.12.22.0-209.12.22.255 //Full Scale Media
>>>>>212.71.224.0-212.71.255.255 //Globix SpA
>>>>>213.219.9.192-213.219.9.255 //Xworks
>>>>>
>>>>
>>>>What is it that we are using to block these IP addresses? Are they
>>>>just being tossed into a users software firewall, router, other
>>>>program?? Would like to participate, but want to be sure that I am
>>>>setting things up correctly...
>>>>
>>>>Thanks!
>>>
>>>
>>>The ideal point would be the router, but few, if any, home user
>>>routers are equipped to handle such tables. Next would be the
>>>firewall - several provide for IP & Range blocks and some make it
>>>easier to administer than others (cut & paste being a big help). The very
>>>last would be an app, such as Peer Guardian, which reacts
>>>to connections made - tho it is among the easiest to employ.
>>>
>>>Rationale: Blocking at the router places no impact at all on the PC.
>>>Blocking in the firewall adds to its burden, which already competes
>>>with other CPU demands. Blocking in a third party app merely
>>>increases the software burden in the PC allowing the router,
>>>firewall, and even MX to react to the connection before it is killed
>>>by the monitor. Bear in mind that, as has been pointed out previously,
>>>these block
>>>lists only apply to Primary nodes and only prevent some connections
>>>to that primary as secondary sources of fake lists. These blocks
>>>have absolutely no effect on the DOS-like attack a primary will
>>>receive from secondary fake lists which have managed to connect to
>>>other primary nodes. The only effective blocking of the fakes via these
>>>lists is by 100%
>>>of the primaries participating with 100% up-to-date lists.
>>>
>>>If the only thing which the WPN had to cope with was filtering fake
>>>sources, there'd be little to concern ourselves with. Much worse is
>>>the impact on primary nodes when floods of fake responses arrive
>>>simultaneously. This is causing secondaries to loose the link and
>>>their queue status along with it, as well as causing primaries to
>>>discard valid traffic replies while trying to cater to the invalid -
>>>and in some percentage of cases, crash (or at least appear to have
>>>done so to the hapless user:-(
>>
>>It would be best all round if the peer cache servers ran PG...
>
>
> I disagree!
>
> This is a behavioral problem, not an IP address problem.
>
> The behavior in question is: answering queries in an overly aggressive
> manner.
>
> If FC were to do anything, and it might be understandable to do so as a
> network integrity measure, it would be to have primary nodes limit responses
> from secondary connections to a piddling few per time period. My own
> variation on this methodology would be to apply the clamps proportionate to
> the responses generated - the more responses to a sinlge query, the longer
> before that secondary may respond again AT ALL.
>
> Now there is NO way that all the primary users will EVER implement anything
> on their own. So FC's concern for net integrity might be the only answer to
> THIS problem. Not to say that there would not be some future problem
> instigated in its stead, but this behavior would be put to an end.
>
> Considering that authors of software considered unfriendly to "the industry"
> are now targets, I'm far from optimistic that FC will even issue the next
> update to WinMX.
>
> Scriptor caveo ;-0)
>
If I understand correctly what is happening with the type 5 fakes, it is
that a hacked or bespoke client gets the addresses of lots of primaries
from the peer cache server and uploads a fake library.dat file to all of
them. Blocking ranges at the cache server would be a good quick fix, but
might have workarounds, such as proxying.
I think cutting down on search responses would help reduce fakes as you
say, but it would also reduce genuine hits.
What about if the peer cache worked the other way around? Supposing a
secondary would announce itself to the peer cache, and then await a
connection with a primary. The primaries would poll the cache server
when they were short of secondaries, and then ask the secondary to
attach. After the secondary connects to the primary the primary could
inform the cache server which could drop that secondary from its list.

Or, another possibility would be for the primary to always request a
random file from the secondary upon connection, and kick the secondary
off if the transfer times out.

Sadly, I don't think FC are going to fix this.

[Back to original message]