Thanks, T. Rob:
I was actually confused: I had remembered I had to define two listeners in inetd on
one machine for some reason and after reading your mail I checked the box and it
turned out it was for 2 different queue managers :-). I definitely need a long nice
vacation...
Pavel
"Wyatt, T. Rob"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
MERICA.COM> cc:
Sent by: MQSeries Subject: Re: Security with Server
Connection channels
List
<[EMAIL PROTECTED]
C.AT>
09/11/2003 08:59 AM
Please respond to
MQSeries List
Pavel,
Multiple SVRCONN channels on same port: Absolutely. Note that there is
nothing in a SVRCONN definition to tie it to a specific listener or port.
Assuming you have a listener, no exits and no LOCALADDR specified, incoming
traffic can start any of your SVR, RCVR, RQSTR or SVRCONN channels from the
same port. Define multiple SVRCONN and they can all be started from the
same listener on the same port.
By the same token, if you have many listeners and only one SVRCONN, traffic
from any listener can start an instance of that SVRCONN.
Keep in mind that you can have many instances of a SVRCONN, RCVR or RQSTR
running simultaneously. So if you set up a channel and a port in the
firewall for USER-A and a different channel and port for USER-B, there is
nothing to stop USER-B from starting USER-A's channel EVEN IF USER-A HAS AN
INSTANCE RUNNING.
-- T.Rob
-----Original Message-----
From: Pavel Tolkachev [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 10, 2003 3:49 PM
To: [EMAIL PROTECTED]
Subject: Re: Security with Server Connection channels
Thanks T.Rob,
CRLs are definitely a good point -- I keep forgetting about this
possibility. Wrt multiple SVRCONN channels: can I actually have several on
same port?
Exit is a way, of course, but only as a last resort.. I am off the problem
right now; if it comes back to me I will probably be looking for some ready
product. Which would be a security exit changing the agent's user id
according to a DN->userId map, specified by me (not sure how I would prefer
to do so though. Maybe with LDAP or configuration file or better I would
have a choice). This is not a call for bids, just an attempt to define what
I would want to have. Once again, I do not have this problem immediately in
front of me.
Thank you again, I suspect your answer was exhaustive.
Pavel
"Wyatt, T. Rob"
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
MERICA.COM> cc:
Sent by: MQSeries Subject: Re: Security
with Server Connection channels
List
<[EMAIL PROTECTED]
C.AT>
09/10/2003 02:56 PM
Please respond to
MQSeries List
Certificate Revocation Lists - Allows you to deny access to any single named
individual while still allowing access to the group via wildcard filter.
MCAUSER - enforces that any user coming in through the channel has
low-privileged access configurable via OAM.
Class of service - multiple SVRCONN channels can provide broad classes of
service to different groups based on their certificates and MCAUSER. One
SVRCONN for the admins, another for the Help Desk and another for the
business users.
Individual authentication - Under SSL, an exit can map certificates to
usernames and you can turn context authority on if you must have
authorizations at the individual user level.
-- T.Rob
-----Original Message-----
From: Pavel Tolkachev [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 10, 2003 2:17 PM
To: [EMAIL PROTECTED]
Subject: Re: Security with Server Connection channels
Thanks Phil,
I actually remembered that, I asked the list about this once before.
Wildcards partially help to authenticate many people (apps), but do not
solve the authentication problem in general (people/applications can have
completely unrelated names or two persons from the same organization must be
able to access different channel). What's worse is that (please correct me
if I am wrong) there is no built-in way to map the name in the certificate
to the agent privileges, so all users authenticated by a particular channel
instance will have same permissions to all MQ objects. Which makes
authenticating many names a bit useless: why would it help to have several
differently named principals with the exactly same set of priviliges?
Especially when it is difficult to deny an access for one of them not
affecting others.
I would speculate that is why many MQers prefer to talk in terms of
authenticating and authorizing applications, not actual people. But this
silently assumes that the actual people were authenticated/authorized to run
applications *before*, so MQ application must be, to some degree, already
trusted. And that is why, company policies aside, personally I do not see
much value in SSL-ing SVRCONN channel except for providing data
confidentiality and server authentication *for the client*. These two, of
course, can be very valuable by themselves.
I will love it if someone tells me I am missing something here -- I have
never had any formal MQ training and I am really interested in "right ways"
to secure MQ servers from the malicious remote clients.
Thank you,
Pavel
[EMAIL PROTECTED]
PMCHASE.COM To:
[EMAIL PROTECTED]
Sent by: MQSeries cc:
List Subject: Re: Security with
Server Connection channels
<[EMAIL PROTECTED]
.AC.AT>
09/10/2003 10:25
AM
Please respond to
MQSeries List
Pavel,
The SSLPEER parameter is actually a filter. Therefore you can code it like
"SSLPEER(CN=APPL*, O=MYCompany, OU=Any*, C=US). This will then permit any
CN prefixed by APPL and any OU prefix by "Any". By using the filter you
can service and validate many different Distinguished Names (SSLPEER).
Phil
Pavel Tolkachev
<pavel.tolkachev@ To:
[EMAIL PROTECTED]
DB.COM> cc:
Sent by: MQSeries Subject: Re: Security with
Server Connection channels
List
<[EMAIL PROTECTED]
n.AC.AT>
09/10/2003 09:28
AM
Please respond to
MQSeries List
Well, denial of service attack is always there, of course (I did not try it
myself with MQ and listener pool, to be completely honest). Of course, I
assume your system will use only SSL channels to have a strong
authentication and confidentiality on the wire. Do not forget to set
SSL_PEER to actually authenticate clients. It is slightly inconvenient
though as you can only accept a single distinguished name per a channel
instance -- but this is how it's done in MQ.
Also, be careful with triggering and DLQ (and DLQ handlers) *inside* the
cluster -- of course, the attacker must penetrate the SSL perimeter to try
to take advantage of them. The threat here is that a legal, but restricted,
user may try to get more privileges in trigger/dlq handler than s/he is
supposed to have. That's one reason why I try to never use any of
triggering / dlq handling.
I am sure there are other threats, just because they are always there
(access to system queues?) but I cannot think of anything concrete right
away. Will let you know if (when?) I will run into anything.
Hope this will help,
Pavel
[EMAIL PROTECTED]
.AU To:
[EMAIL PROTECTED]
Sent by: MQSeries cc:
List Subject: Security with
Server Connection channels
<[EMAIL PROTECTED]
n.AC.AT>
09/10/2003 01:33
AM
Please respond to
MQSeries List
Howdy all,
I need some thoughts on possible security vulnabilities.
If I have an MQ server being used as a gateway into a cluster, (it holds no
queues) and no command server is running and a pool of listners are running
for clients to connect with using a server connection channel, can anyone
do anything malicious to my cluster.
The platform would be Linux (red hat) and MQ v5.3 is installed, no other
inetd services are installed.
____________________________________________
Sid Young B I.T. (cs dc) AD (cse)
DBA
Intranet Developer
Analyst / Programmer
Information Systems Department
[EMAIL PROTECTED]
QML Pathology Phone: (07) 3840 4941 Fax: Fax??? This is the 21st Century!
www.qml.com.au
60 Ferry Rd
West End, QLD 4101
--
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
This communication is for informational purposes only. It is not intended
as
an offer or solicitation for the purchase or sale of any financial
instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.
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
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
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
