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