Posted by Don M. on 10/02/05 02:40

"db" <@ .> wrote in message news:433dc4cf$0$16336$ed2619ec@ptn-nntp-reader01.plus.net...
>
> "Billy Joe" 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".
>
=======

I can see why you would need that. :)
In the meantime I'll go bang my head against a wall until it stops hurting. BBL.


Don

[Back to original message]