Hello Randy,
If you leave MCAUSER blank (' '), the channel agent will actually run on behalf of the
user as reported by the client. The details of user names used are in the book (mostly
"Clients" and "Intercommunication" as far as I can remember) but they depend on both
client platform and server platform. For NT to NT, I beleive, the "strongest" security
check is performed which involves domain controller and similar stuff (like user
provides its SID or something similar -- but do not hold me to it please)).
Yes, it is mostly "authentification by assertion" especially if you beleive the
attacker can forge the MQ protocol completely. But still slightly better than nothing.
SSL looks the way to go. I got it working, with streaming type of ciphers like RC4 x
128 x SHA it must be reasonably fast and reliable. 3DES would slow down things, but
even using it I do not beleive SSL would become a bottleneck, especially considering
MQ performance. Much faster MOMs like those from Tibco or Vitria are using SSL and
that makes me think the slowdown will be relatively insignificant with MQ. What will
suffer is an initial connection time because the keystore decryption algorithms are
traditionally made slow -- and for good reasons. It takes especially a while to
complete any single operation with .kdb database with IBM's gsk; JDK's keytool is much
faster working with .jks databases but still takes time. (your SSL participants may
need to use both: queue manager will use kdb and client can use .kdb (C clients, not
tried) or .jks (Java clients, tried)).
Hope this will help,
Pavel
"Crowder, Randall"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
ALCITY.COM> cc:
Sent by: MQSeries List Subject: Re: Stopping NT
Local/System account access for the client
<[EMAIL PROTECTED]
T>
06/18/2003 04:37 PM
Please respond to
MQSeries List
Thanks Wyatt,
This is great info... I don't think the MCAUSER parm is really what I need.
It appears that it just gives the connecting client the rights of the user
specified in MCAUSER (as checked by OAM)... What keeps an ill intentioned
person from connecting to another server conn channel?
Sounds like the exit that restricts by incoming IP is more like what I
need... I don't really want to use SSL because of the overhead.
Thanks again...
Randy
-----Original Message-----
From: Wyatt, T. Rob
To: [EMAIL PROTECTED]
Sent: 6/18/03 3:02 PM
Subject: Re: Stopping NT Local/System account access for the client
Randy,
Client connections are very unsecure by default but you can tighten them
up
quite a bit. Whatever ID runs the listener is potentially used by the
OAM
to check authorities. If you use a channel exit or specify an MCAUSER,
you
can force the ID to be a low-privileged user - but only for that
specific
channel. Remember, just because you protect SOME.APP.SVRCONN with an
exit
or MCAUSER, doesn't mean an intruder won't try to come in through
SYSTEM.DEFAULT.SVRCONN instead. And if you secure all the SVRCONN
channels,
they can easily put up a SDR to connect to one of your RCVR/RQSTR
channels.
It's kind of a pain to manipulate the listener process ID and use
MCAUSERs
because you need some kind of administrative access to the box so the
usual
solution is to use an exit of some sort. This is true across all the
distributed platforms, BTW, not just Wintel.
Jørgen Pederson wrote a small exit program that filters connection
requests
by IP. I think he's trying to get it released as a Support Pac but in
the
meantime he's made it available at:
http://home19.inet.tele.dk/m-invent/ Click on "Tips And Tricks" then
look
for the link to "BlockIP Security Exit". He provides source as well as
Windows DLL. It's very effective as is or you can use it as an starting
point and add your own features in.
-- T.Rob
-----Original Message-----
From: Crowder, Randall [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 17, 2003 10:00 AM
To: [EMAIL PROTECTED]
Subject: Stopping NT Local/System account access for the client
All,
Probably not news to anyone else, but I have discovered what I believe
is a
major security hole with the Client... For NT/2000 it appears that as
long
as a service is running under the local/system account, if it can client
connect to an NT/2000 queue manager with full rights.
I have a test "service" that I install and run under my local system
account. It uses the client to connect to a queue manager and then puts
a
test message on the SYSTEM.DEFAULT.LOCAL.QUEUE. Regardless of how a
queue
manager is secured with setmqaut, as long as the service runs under
local/system, it can connect to the queue manager and put messages.
Beyond using SSL, is there any way around this behavior?
Thanks,
Randy
Randy Crowder
National City Corp
Strategic Technology Services - Infrastructure Integration
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
