Posted by bigrustyc on 09/26/05 09:11

Many thanks for the tip - much appreciated!

R


On Sun, 25 Sep 2005 08:09:04 -0700, "Billy Joe"
<see.id.line@invalid.org> wrote:

>As mentioned here by fred-bloggs, the HOSTS list - which does work - needs
>to be edited when downloaded from sources listed here. Alignment is the
>best way of checking that the edit was done correctly.
>
>Connection as a primary is quite quick (no different than I recall when FC
>ran the peer cache). Connection as a secondary is somewhat slower, as much
>as 4 minutes.
>
>As a primary, I have 2 firewall tweaks in use:
>
>a) block ALL inbound TCP/UDP traffic to WinMX from remote ports above 8,000
>(this would be the OS assigned outbound port on *their* system, NOT the
>WinMX designated input port on their system). Very few of us ever use
>outbound, OS assigned ports with values higher than 6000 as it would require
>a whole lot of network usage to get there. This would be much more
>characteristic of the fakers who establish a multitude of connections (and
>possibly some gamers, running MX in the "background")
>
>With this block in effect, the first secondary did not attach for almost 6
>minutes. Without it, secondaries fill to the max in barely a minute.
>
>This block would serve little purpose when running as a secondary, but no
>real harm would be done with it left in place.
>
>b) block ALL in/outbound traffic system-wide for any of the host addresses
>or ranges appearing in the list suggested here in the past. If you seem to
>get more web pages becoming unavailable, you could make this block WinMX
>specific.
>
>Type a) blocks occur at about 2 per second and include TCP & UDP
>occurrences, with the ratio being steeply TCP (attempted connections) until
>the secondary count gets saturated. A secondary search for a fake shows up
>as a large spike of inbound UDP and the filter kicks out well over a
>thousand responses (800 or so may still get through to WinMX). The
>down-side, I need to turn off firewall logging and address/port resolution
>or it (the Kerio firewall) comes to a halt - graphically! The up-side,
>WinMX operates as normal.
>
>Type b) blocks show up in spurts but are a significantly small percentage,
>when compared with a). There is no evidence, of course, that this block is
>NOT merely preventing peers from accessing this system.
>
>For those primary users who may not be filtering, here are the settings for
>Kerio:
>"Network Security" tab, "Packet filter ..." button
>"IP Groups" tab
> Click "Add" to enter an IP host or range
> "is enabled" checked
> "Group name" enter a unique name for each group
> "description" only necessary when more than one entry
> will be made within the group. I simply used numbers.
> "type" select "host" or "range" from the pull down
> "host (or first/last) address" enter the xxx.xxx.xxx.xxx value
>
>If you add more *lines* to the group, just select the group name from the
>pull down the next time thru these steps.
>
>If you make more than one group, just type a new group name the next time
>thru.
>
>Now select the "Filter Rules" tab.
>Click "Add"
>description: (enter-> Block ports above 30000)
>application: c:\program files\winmx\winmx.exe (or wherever you have it)
>group: enter a name, I've used "HighPorts"
>log to network log (initially check this so you can see the results)
>Protocol: click Add, enter TCP as the name - the rest will be filled in by
>Kerio.
> Click Add a second time and enter UDP as the name.
>Local: leave this empty
>Remote: Click Add, only the first & last numbers need be entered
> 30000 & 65535
>Direction: Incoming
>Action: Deny
>
>
>Save this rule and click the Add button under Group Name once again.
>description: (enter -> MP/RIAA)
>application: any
>group: MP-RIAA
>log to network log (initially check this so you can see the results)
>protocol: same as above
>Local: leave this empty
>Remote: Click Add, select the group name created above
> If you created more than one group above, repeat for each.
>Direction: Both
>Action: Deny
>
>Type b) addresses, as I've recorded them:
>38.119.64.0 - 255
>72.35.224.0 - 255
>204.9.117.0 - 255
>204.193.136.104 (single host)
>209.10.143.0 - 255
>209.11.134.0 - 255
>212.71.252.122 (single host)
>213.219.9.0 - 255
>
>These filters, both a) & b), kick in immediately, MX does not have to be
>restarted, if it was running.
>
>
>As for stability, MX operates as usual. However, I've had to reboot the
>NetGear WGR614v5 router five times in three days (all connections lost). On
>none of these occasions was I at the console to read the short-term activity
>graphs and I have logging turned off, so I can only presume that the filters
>don't catch everything and that WiFi (1/3 the speed of the 8mbps cable
>connection) is not the best way to run an MX primary under present
>circumstances?? ;-0)
>
>HTH
>BJ
>

[Back to original message]