Posted by Billy Joe on 09/25/05 15:09

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]