Posted by Billy Joe on 09/30/05 17:40

db wrote:
> "Triffid" <spamme@microsoft.com> wrote in message
> news:433c7aef@212.67.96.135...
>> db wrote:
>>> "Billy Joe" <see.id.line@invalid.org> wrote in message
>>> news:16adneSwEYLo-6HeRVn-oA@adelphia.com...
>>>
>>>> db wrote:
>>>>
>>>>> "Billy Joe" <see.id.line@invalid.org> wrote in message
>>>>> news:FICdnfvoLv0JxaHeRVn-ig@adelphia.com...
>>>>>
>>>>>> I did notice today, when testing this, that the banned IPs
>>>>>> listed in my firewall showed up immediately and in larger number
>>>>>> than over the past several days. I also noticed that this
>>>>>> appeared to be the same, whether using the ws2_32.dll or HOSTS
>>>>>> files. Can't draw a conclusion from so limited a test tho.
>>>>>
>>>>> I logged 15 THOUSAND connection attempts from 'them' yesterday.
>>>>> Insane...
>>>>
>>>> They must have you targeted, db. I was nowhere near that high!
>>>>
>>>> I do notice that, once I have been visited by one or several, the
>>>> next time I log on with the same ports open they are the first to
>>>> show up here.
>>>>
>>>> I've set up a slightly wider range of ports in the router, and
>>>> bump the numbers each time I start MX.
>>>>
>>>> Hell, it's all a game, isn't it?? ;-0)
>>>>
>>>> BJ
>>>
>>>
>>> It's an interesting game for sure. Stats for today, only 12,742
>>> attempts this time, weeeeee (though prolly because I wasn't running
>>> primary for 24 hours today).
>>>
>>> They're not a problem here though so long as the door doesn't get
>>> answered. :)
>>>
>>>
>>>
>>
>> You got me worried now. Is this PeerGurdian we're talikng about
>> here, I've never bothered till now. Should I?
>
> P.S. Peerguardian, not necessarily. There's plenty of ways to block
> them, some requiring significant hands-on ability (using your
> firewall/router/etc), some requiring updating manually & frequently
> (PeerGuardian / Protowall) and one that will update automatically if
> so long as it works correctly for you (the WS2_32.DLL fix going
> about).
> I'd go for the WS2_32.DLL fix if possible (possibly only working
> correctly on Windows XP at the moment, though maybe Win2K also (not
> suitable for Windows 98/ME)).

I know that we don't agree on the proscribed IP list idea, db. But our
goals are the same, to utilize MX with little or no malicious interference.

I've been concentrating on your observation regarding the OS allocated TCP
port utilized by inbound connection attempts.

I've set up two "packet filters" in Kerio 4.2 personal firewall:

1) The proscribed IP lists found among posts within this NG in the past few
days

presently in my list:

38.113.214.*
38.119.64.*
63.216.0.0-223.255
64.248.57.132
66.166.198.203
67.101.77.191
68.165.91.118
70.51.124.42
72.35.224.*
81.151.195.148
81.156.180.20
81.158.250.176
81.158.253.172
86.134.204.87
88.109.80.133
204.9.116.*
204.193.136.*
206.161.141.*
209.10.143.64-95
209.11.134.*
209.12.22.*
209.195.0.*
209.195.58.*
212.71.224.*
212.71.252.*
213.219.9.*
213.219.191.*
216.151.155.*

2) Any inbound TCP connection from a port over 4000
(set up as 4001 thru 65535)

I'm a little handicapped in analyzing the results, as the free version of
Kerio will not write the log to disk. But I can visually scan across the
thousands of log entries and draw some conclusions.

a) Virtually all the priority 1) blocks would have been trapped by 2)

b) The vast majority of priority 2) blocks are using ports well above 20000,
which carries an implication of its own regarding those IPs.

Also, reversing the priority of the filters yields no blocks from the
proscribed list in the first hour of observation, implying all were trapped
by the limited inbound port filter. That small number having been noted in
a) simply did not attempt to connect during this observation period, but
would have shown up had they. No inference as to whether those attempts
were, or were not, from otherwise valid MX users.

So, what I'm suggesting, since updating the proscribed list is not
automatic, quite unreliable, and possibly inaccurate is that the second
filter be used, if not exclusively, at least as a backup to the first.

This is clearly something that can not be done, at the moment, by PG & its
ilk. And, I'd feel relatively safe with only priority 2) in place, which
would probably also make Kerio happier. If the revised DLL has this
ability, it would seem not only simpler but fairly reliable.

For those using firewall software that can block by allocated port, setting
up the port filter is certainly easy, not time consuming, and far less typo
prone. It would not obviate the use of PG or whatever other toys one wants
to have running.

Are any valid MXer's being kept from connecting to me via either of these
filters? Sure! However, I am maxed out on primary & secondary connections.
And, those who find themselves unable to connect, usually shut down (out of
frustration) and restart, thus dropping their OS allocated TCP port value
back to 1024. The bad guys NEVER shut down. Because, they're unattended
and if they did, then they'd also free up a whole lot of secondary slots for
the rest of us.

BJ

[Back to original message]