|
|
Posted by anthonyberet on 09/07/05 22:50
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...
Navigation:
[Reply to this message]
|