|
|
Posted by db on 09/30/05 20:16
"Billy Joe" <see.id.line@invalid.org> wrote in message
news:LdCdndwNvLwF5aDeRVn-sA@adelphia.com...
>
> 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'm aware of what you're referring too but it's no big deal. My only
interest is not to 'save the WPN' as such, but rather to pass on the
information that I've learnt over time for the benefit of others (if they
find that information useful). Look at it as some base information that
could lead onto better things.
Anyway, things could be changing now.
> 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.
If it has the capability of logging out to syslog that could be very useful
for tinkering.
> 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.
Yeah, the block-by-source-port seemed very effective when I was using it
here, but, I moved away from that after a while as I'm not comfortable with
the collateral damage of it (>32768 = blocked). Very good method of taking
care of the dynamics, though, IMO.
Note: Will only work for one of the systems the fakers appear to be
operating (I see 2 in general).
> 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.
Hmm, I'd be surprised if the >4000 block took care of them all (checks
logs)... (picks random entry) 63.219.21.43,2486 -> 192.168.1.2,666 PR tcp
len 20 48 -S 575397148 0 64240 IN, there's a big static faker with source
port 2486. It's possible that all of the 'low source port' type of fakers
are running on statics (of the top of my head I believe they do), whereas
all of the dynamics run from high ports (I'd need to run through the logs
here to verify that though can't be arsed).
> 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.
Maybe the WS2_32.DLL could be a better solution? :P
I think your list is quite inaccurate as it contains IP addresses that I
haven't seen operating of late. I try to keep my own lists as small and
accurate as possible now for manageability. I'll leave the various dynamic
entries listed for about a week then run through the logs to see which are
no longer active (one of the most difficult things for me is discovering
when addresses go inactive, as opposed to active).
> 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.
Aye, I had a good talk with a dev of PW once about this, though, as you
rightly say, PW/PG simply do not have that ability (I don't think it's a
particulary good way to block anyway, personally).
Dunno about the DLL potentially doing that. How about a DLL that has the
capability to detect, log & block automatically based on a local 'database'
of sorts that counts how often a particular IP has attempted connection
during a period of time? Just a thought (one striking difference between
legitimate & hostile addresses is the massive difference in the number of
connection attempts seen by them). Anyway, I don't really wanna talk about
this as I'm in no position to create such a thing so it's useless dwelling
over it.
> 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.
Or just run the DLL. ;)
> 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.
Well I stopped using that method when I saw legitimate users trying to grab
a file or two from me but repeatedly time out due to the source port rule.
I don't like that.
> BJ
Regards,
db.
Navigation:
[Reply to this message]
|