Posted by Billy Joe on 09/30/05 21:05

db wrote:

<snip>

>> 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.
>

Not a freebie feature.
Unfortunately, the for-a-fee version offers NADA beside the log to disk that
one could possibly want:-(

>> 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).
>

When you've the time to elaborate, I'm ready to read;-0)
If you already have, and I've missed it, sorry - a ref would help.

>> 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).

Didn't mean to imply it "took care of them all." The last two sentences, my
weak essay ability showing, being an attempt to explain that.

>> 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
>

It would be wonderful, but so far merely implications of its doing so. Any
details on how it may be doing it? It is certainly a small piece of code !!

> 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).

The list shown is exclusively garnered from posts here - so, it serves my
point that the average user will NEVER have an accurate list, no?

>> 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.
>


Now we're back to our philosophical differences;-0)

I believe that the primaries need an add-on that will block OUTBOUND bad
behavior. With such, IP addresses become moot. When last we exchanged on
this point, MX seemed on the verge of (OK, on the same mesa as) 4.0. So
there would have been little value in expending effort on such a program.
Add to that, the incredible short-fall from 100% of the primaries ever doing
anything - including becoming aware of the issues.

Now MX is in stasis. So an effort to do something along these lines seems
more feasible, hoping that there is a way to then achieve primary
penetration with a solution.

What I know I can do programmatically (therefor anyone can):
Find the MX client and intercept its Windows message traffic.

What I don't know, until trying it, is:
Can I see the search reply's secondary ID? If so, then log the number of
replies per second per secondary (better still, per search, if that can be
done).

If the above can be done, then:

Simple action a) prevent subsequent replies for n time periods from abusive
secondaries.

More complicated action b) disconnect the secondary

>> 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. ;)
>

You keep saying this, but WTF does it do??? Any details?

>> 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.
>

On the one hand, folks say: any solution, no matter how imperfect, is better
than none.

On the other hand you're saying: if at all imperfect, abandon it in favor of
allowing some incursion.

OK! Whatever ;-0)

BJ

[Back to original message]