|
|
Posted by db on 09/30/05 23:05
"Billy Joe" <see.id.line@invalid.org> wrote in message
news:FYGdndgvcO8PNaDeRVn-gg@adelphia.com...
Bloody hell, here it goes... :)
> 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:-(
I always thought you were a die-hard 2.1.5 person, Billy? :p
>>> 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.
Not too sure what you'd like info on there. Giz a shout and I'll see what I
can do answer.
>>> 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 !!
(now bare in mind I'm not a programmer here!)...
As I understand it it's a Winsock wrapper like;
WinMX <-> WS2_32.DLL (fix) <-> WS2_32.DLL (system)
I think all the DLL does is tap into some of the 'exports' functions of the
actual Windows system WS2_32.DLL in order to work them. The exports are the
following afaik;
111 1A 00001740 WSAGetLastError
1 51 0000868D accept
2 52 00003ECE bind
3 53 00001A6D closesocket
4 54 00003E5D connect
94 55 00003A2C freeaddrinfo
95 56 000033DF getaddrinfo
51 57 0000D755 gethostbyaddr
52 58 00002BBF gethostbyname
57 59 000032CA gethostname
96 5A 0000C076 getnameinfo
5 5B 0000F628 getpeername
53 5C 0000D24E getprotobyname
54 5D 0000D1A2 getprotobynumber
55 5E 0000D969 getservbyname
56 5F 0000D850 getservbyport
6 60 0000157E getsockname
7 61 00004122 getsockopt
8 62 000012A7 htonl
9 63 00001746 htons
11 64 000012F8 inet_addr
12 65 0000401C inet_ntoa
10 66 0000155A ioctlsocket
13 67 00005DE2 listen
14 68 000012A7 ntohl
15 69 00001746 ntohs
16 6A 00005690 recv
17 6B 00001444 recvfrom
18 6C 00001890 select
19 6D 00001AF4 send
20 6E 00001ED3 sendto
21 6F 00003F8D setsockopt
22 70 00008629 shutdown
23 71 00003C22 socket
I think the DLL basically passes most of those straight through without any
manipulation at all on to the actual real Windows WS2_32.DLL, though some
are tapped into, like 'closesocket', 'recv', 'recvfrom', 'send', 'sendfrom',
or whatever, that handles the information we need to manipulate. Afaik once
you have these tapped then it's not too much work to allow or deny traffic
based on the IP being passed through the DLL. The WS2_32.DLL fix online
automatically downloads a blocklist of addresses from
http://www.winmxgroup.com/block_list.txt each time WinMX is started and so
the DLL checks IP addresses that run through it against those in the
downloaded list and simply allows/denies accordingly.
The other function of the DLL I'm aware of is to modify outbound calls from
WinMX for the original 'winmx.com' cache servers to 'winmxgroup.com'
instead, similar to how the hosts file mod works though not directly
translating a domain name to IP, just modifying the domain name as it passes
through the DLL. You can see the domain names listed in plaintext in the
DLL easily enough (as with the exports, btw);
cache9.winmxgroup.com,
cache8.winmxgroup.com,
cache7.winmxgroup.com,
cache6.winmxgroup.com,
etc.
I think that's how it works anyhow... :s
(abysmal explanation there, I know, but hopefully it's basically correct!)
>> 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?
But they would if they ran the DLL fix, and the list on their site was
accurate (which is my reasoning for pushing it (and the list looks good so
far)), then it'd take all the hard work out. It should require zero
maintenance by the enduser.
>>> 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.
Block outbound behaviour? Why, and how (realistically)? :P
BTW: note that the closure of the caches and subsequent (is that the right
word?) user requirement for a fix to get online has provided a significant
opportunity to address the issue of getting the users to actually do
something (whereas before, I agree, and ALWAYS HAVE, that it was as good as
futile to try to achieve this (some 'intelligent' people out there still
seem to think they can get everyone to run PG/PW, though...)).
> 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 I understand you correctly you'd still have some fakes returned (though a
lot less), although it'd do nothing to cure DOS type problems seen, and
possibly other happenings (I see things that don't seem related to typical
'faker' type clients).
Anyhow, afaik, you can indeed identify the file server's IP in the search
packets returned (note 'fserv ip' in below);
Search result (primary) id: 0x177A
Packet format:
[Search ID:4][primary ip:4][primary udp:2][Puzzle:5][File path:N]...
....[00:1][hash:20][Size:4][connec:2][options:*][fserv ip:4][username:N]...
....[00:1][queue status:N][00:1]
> If the above can be done, then:
>
> Simple action a) prevent subsequent replies for n time periods from
> abusive secondaries.
All it'd do is filter them from showing locally though?
> More complicated action b) disconnect the secondary
Now you've lost me (not difficult)? Are you still talking about outbound
here, if so, I've lost the plot totally at this point. :p
>>> 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?
Hope the above helped (if even accurate).
>>> 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.
Long path to learning IMO. ;)
> On the other hand you're saying: if at all imperfect, abandon it in favor
> of allowing some incursion.
>
> OK! Whatever ;-0)
>
> BJ
In the infamous words of Don M, long, long ago: "I need to go lie down for a
while".
Navigation:
[Reply to this message]
|