Posted by Billy Joe on 09/08/05 00:04

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)

BJ

[Back to original message]