Server connection channel and Queue's
Hi fellow MQ users. I have a question to ask about Server connection channels and their queue's. If I define 1 server connection channel on a Z/OS mainframe and have 2 clients that connect to it that would use the same reply, request and dead letter queue. How does MQ know which client to send the response to? I.E. 1 server channel called SRV.X 1 queue called xx.request 1 queue called xx.reply 1 queeu called xx.dead.letter 2 clients on a 2 separate windows boxes that connect to SRV.X They both will write the request to xx.request that will trigger a cics program. The cics program will receive the request and write the response to xx.reply. Both clients will read from xx.reply for the answer. How do the clients know what response is for them? Any help would be appreciated. Thanks in Advance. 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
Re: Server connection channel and Queue's
Client should save either MsgId or CorrId so that it can do a GET for the message it is looking for. By default MsgId is moved into Corrid, but this behavior can be changed. Raj 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
Re: Server connection channel and Queue's
With that setup, both clients are sharing the same reply queue. MQ doesn't really send the reply anywhere--it just puts the reply message on the shared xx.reply queue which is local to Z/OS. It's each client's resonsibility, then, to retrieve only the replies it wants--presumably the ones generated by the request it issued. The customary approach is to coordinate msgid/correlid so the client knows which messages to retrieve. BTW, the DLQ does not belong in this discussion. There is always one per qmgr and it is unknown to the client. -Original Message- From: Ward, Mike S [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 2:29 PM To: [EMAIL PROTECTED] Subject: Server connection channel and Queue's Hi fellow MQ users. I have a question to ask about Server connection channels and their queue's. If I define 1 server connection channel on a Z/OS mainframe and have 2 clients that connect to it that would use the same reply, request and dead letter queue. How does MQ know which client to send the response to? I.E. 1 server channel called SRV.X 1 queue called xx.request 1 queue called xx.reply 1 queeu called xx.dead.letter 2 clients on a 2 separate windows boxes that connect to SRV.X They both will write the request to xx.request that will trigger a cics program. The cics program will receive the request and write the response to xx.reply. Both clients will read from xx.reply for the answer. How do the clients know what response is for them? Any help would be appreciated. Thanks in Advance. 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
MS SQL 2000 Server Connection in WMQI
Hi all Has anyone tried connecting to SQL 2000 using WMQI compute node running on Windows 2000? I have tried to create an ODBCand I get anODBC connection errorwhen I run atrace on the computenode. It says the ODBCwas not found! Any uncounted this? regards Tsietsi
Re: MS SQL 2000 Server Connection in WMQI
Question: Is the broker running on Windows also? Is the broker and SQLServer running on the same box? When you start the ODBC tracing from the Data Sources GUI, do you get any output? B -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Molai TsietsiSent: Thursday, November 06, 2003 10:12 AMTo: [EMAIL PROTECTED]Subject: MS SQL 2000 Server Connection in WMQI Hi all Has anyone tried connecting to SQL 2000 using WMQI compute node running on Windows 2000? I have tried to create an ODBCand I get anODBC connection errorwhen I run atrace on the computenode. It says the ODBCwas not found! Any uncounted this? regards Tsietsi
Re: Security with Server Connection channels
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
Re: Security with Server Connection channels
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
Re: Security with Server Connection channels
Title: Message Sid, Given only the information in your email, the answer would be "Yes, malicious activity could occur". To fully answer that question one would need to know the rest of the configuration. Are the listeners running under a low-privileged ID or as mqm? The clients andcluster on different ports? Are the clients behind a firewall or otherwise restricted as to which port they specify? Any exits or SSLin place? What SVRCONN channel are they using and have you secured or deleted the default SVRCONN channels? Did you delete the default model queue? With no Command Server, the clients are limited as to what they can do on the local machine but what is to prevent them from sending messages to remote command servers? Anything traveling over the cluster channels is almost surely entering the remote QMgrswith mqm authority inherited from the MCA. Even assuming you've deleted the model queue and the client cannot create a valid dynamic reply-to queue, that only prevents the replies from getting back. Any PCF commands that actually reach a command queue on the cluster will still be executed. -- T.Rob -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]Sent: Wednesday, September 10, 2003 1:34 AMTo: [EMAIL PROTECTED]Subject: Security with Server Connection channels 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 YoungB I.T. (cs dc) AD (cse) DBAIntranet DeveloperAnalyst / 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 RdWest End, QLD 4101
Re: Security with Server Connection channels
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: MQSeriescc: 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
Re: Security with Server Connection channels
Just as a matter of interest. Does anyone know of any actual, real world, deliberate, sophisticated, malicious, penetration of an MQSeries installation, and if so, what was the consequence? Matt. -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: 10 September 2003 14:28 To: [EMAIL PROTECTED] Subject: Re: Security with Server Connection channels 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: MQSeriescc: 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 message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. == 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
Re: Security with Server Connection channels
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: MQSeriesSubject: 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: MQSeriescc: 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
Re: Security with Server Connection channels
Pavel, Could you explain how a user could obtain more privilege vis-a-vis the dlq handler? Pavel Tolkachev pavel.tolkachev To: [EMAIL PROTECTED] @DB.COM cc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.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: MQSeriescc: 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 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
Re: Security with Server Connection channels
Couple of my friends used to complain people tried to break their system all the time (like tens times a day). I do not actually know any consequences and even if I knew I would not be allowed to discuss them. It was not a pure MQ system, it included a custom authentication/authorization layer and firewalls (armed with which they were actually learning about the attacks -- hopefully, about all of them), so probably there were no consequences at all. Pavel Gurney, Matthew [EMAIL PROTECTED]To: [EMAIL PROTECTED] SFB.COM cc: Sent by: MQSeriesSubject: Re: Security with Server Connection channels List [EMAIL PROTECTED] n.AC.AT 09/10/2003 10:09 AM Please respond to MQSeries List Just as a matter of interest. Does anyone know of any actual, real world, deliberate, sophisticated, malicious, penetration of an MQSeries installation, and if so, what was the consequence? Matt. -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: 10 September 2003 14:28 To: [EMAIL PROTECTED] Subject: Re: Security with Server Connection channels 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: MQSeriescc: 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 message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all e
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: MQSeriesSubject: 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: MQSeriescc: 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
Re: Security with Server Connection channels
I'm not sure I agree with your contention that a DLQ would enable a user to gain more privileges. Also, by not having a DLQ, you could also stop the channel by trying to send a message to a bogus remote queue. This would, in effect, also deny legitimate messages from being sent. Pavel Tolkachev pavel.tolkachev To: [EMAIL PROTECTED] @DB.COM cc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.AC.AT 09/10/2003 01:49 PM Please respond to MQSeries List Well, by default the default dlq handler is running as mqm. One thing the user who is allowed to publish messages can always do is to overflow his queue, deny others access to the dead letter queue (by flooding it as well) and, subject to his knowledge of the dlq rules in effect, and the rules themselves, try to achieve forwarding his or her messages to other queues where s/he does not belong. Pavel Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 10:37 AM Please respond to MQSeries List Pavel, Could you explain how a user could obtain more privilege vis-a-vis the dlq handler? Pavel Tolkachev pavel.tolkachev To: [EMAIL PROTECTED] @DB.COM cc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.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: MQSeriescc: 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
Re: Security with Server Connection channels
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: MQSeriesSubject: 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
Re: Security with Server Connection channels
In regard to the dlq, making use of the MCAUSER on a receiver channel might lend a hand (this will not work for client connections). When the MCAUSER on a receiver channel is non blank it behaves much different than a server connection for a client. For a receiver you have to set the authorizations as follows to avoid getting a troublesome 2035: Authorizations needed for queue manager: +inq, +connect, +set, + setall Authorizations needed for destination queue and DLQ: +put and +setall So, on selected receivers, you could block access to the dlq by not doing the +put thing, and still have it available for authorized users. Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 02:22 PM Please respond to MQSeries List I'm not sure I agree with your contention that a DLQ would enable a user to gain more privileges. Also, by not having a DLQ, you could also stop the channel by trying to send a message to a bogus remote queue. This would, in effect, also deny legitimate messages from being sent. Pavel Tolkachev pavel.tolkachev To: [EMAIL PROTECTED] @DB.COM cc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.AC.AT 09/10/2003 01:49 PM Please respond to MQSeries List Well, by default the default dlq handler is running as mqm. One thing the user who is allowed to publish messages can always do is to overflow his queue, deny others access to the dead letter queue (by flooding it as well) and, subject to his knowledge of the dlq rules in effect, and the rules themselves, try to achieve forwarding his or her messages to other queues where s/he does not belong. Pavel Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 10:37 AM Please respond to MQSeries List Pavel, Could you explain how a user could obtain more privilege vis-a-vis the dlq handler? Pavel Tolkachev pavel.tolkachev To: [EMAIL PROTECTED] @DB.COM cc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.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: MQSeriescc: 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
Re: Security with Server Connection channels
How would you decide who, or who isn't an authorized user? The contention is/was that we could have a malicious user, who could be an authorized user as well. Bill Anderson [EMAIL PROTECTED] To: [EMAIL PROTECTED] ITA.AEROcc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.AC.AT 09/10/2003 03:24 PM Please respond to MQSeries List In regard to the dlq, making use of the MCAUSER on a receiver channel might lend a hand (this will not work for client connections). When the MCAUSER on a receiver channel is non blank it behaves much different than a server connection for a client. For a receiver you have to set the authorizations as follows to avoid getting a troublesome 2035: Authorizations needed for queue manager: +inq, +connect, +set, + setall Authorizations needed for destination queue and DLQ: +put and +setall So, on selected receivers, you could block access to the dlq by not doing the +put thing, and still have it available for authorized users. Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 02:22 PM Please respond to MQSeries List I'm not sure I agree with your contention that a DLQ would enable a user to gain more privileges. Also, by not having a DLQ, you could also stop the channel by trying to send a message to a bogus remote queue. This would, in effect, also deny legitimate messages from being sent. Pavel Tolkachev pavel.tolkachev To: [EMAIL PROTECTED] @DB.COM cc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.AC.AT 09/10/2003 01:49 PM Please respond to MQSeries List Well, by default the default dlq handler is running as mqm. One thing the user who is allowed to publish messages can always do is to overflow his queue, deny others access to the dead letter queue (by flooding it as well) and, subject to his knowledge of the dlq rules in effect, and the rules themselves, try to achieve forwarding his or her messages to other queues where s/he does not belong. Pavel Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 10:37 AM Please respond to MQSeries List Pavel, Could you explain how a user could obtain more privilege vis-a-vis the dlq handler? Pavel Tolkachev pavel.tolkachev To: [EMAIL PROTECTED] @DB.COM cc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.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
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: MQSeriesSubject: Re: Security with Server Connection channels List [EMAIL PROTECTED] n.AC.AT 09/10/2003 09:28 AM
Re: Security with Server Connection channels
Pavel, I actually build a Security Exit to address your concern. It checks either the incoming IP address or the incoming SSLPEER against a list of SSLPEER (Distinguished Names) and/or IP addresses, and then assigns a corresponding user id to the MCAUSER field. The exit can also be used to validate any other channel type as well. With Sender types, however, setting the MCAUSER has no affect, so its necessary to CLOSE the channel if their identity is not on the list. You could always create a new channel for every possible MQClient and hard code the SSLPEER, but what a pain to administer. Phil Pavel Tolkachev pavel.tolkachev@To: [EMAIL PROTECTED] DB.COM cc: Sent by: MQSeriesSubject: Re: Security with Server Connection channels List [EMAIL PROTECTED] n.AC.AT 09/10/2003 02:17 PM Please respond to MQSeries List 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: MQSeriesSubject: 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
Re: Security with Server Connection channels
Well, I suppose that is more of a business oriented question than a technical one. But, if you delete the dlq completely, its a done deal right, NOBODY can use it because its not there. If you use the MCAUSER to restrict access to some, it is still available for legitimate use. How you choose who can and who cannot talk to it is another issue. Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 03:38 PM Please respond to MQSeries List How would you decide who, or who isn't an authorized user? The contention is/was that we could have a malicious user, who could be an authorized user as well. Bill Anderson [EMAIL PROTECTED] To: [EMAIL PROTECTED] ITA.AEROcc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.AC.AT 09/10/2003 03:24 PM Please respond to MQSeries List In regard to the dlq, making use of the MCAUSER on a receiver channel might lend a hand (this will not work for client connections). When the MCAUSER on a receiver channel is non blank it behaves much different than a server connection for a client. For a receiver you have to set the authorizations as follows to avoid getting a troublesome 2035: Authorizations needed for queue manager: +inq, +connect, +set, + setall Authorizations needed for destination queue and DLQ: +put and +setall So, on selected receivers, you could block access to the dlq by not doing the +put thing, and still have it available for authorized users. Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 02:22 PM Please respond to MQSeries List I'm not sure I agree with your contention that a DLQ would enable a user to gain more privileges. Also, by not having a DLQ, you could also stop the channel by trying to send a message to a bogus remote queue. This would, in effect, also deny legitimate messages from being sent. Pavel Tolkachev pavel.tolkachev To: [EMAIL PROTECTED] @DB.COM cc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.AC.AT 09/10/2003 01:49 PM Please respond to MQSeries List Well, by default the default dlq handler is running as mqm. One thing the user who is allowed to publish messages can always do is to overflow his queue, deny others access to the dead letter queue (by flooding it as well) and, subject to his knowledge of the dlq rules in effect, and the rules themselves, try to achieve forwarding his or her messages to other queues where s/he does not belong. Pavel Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 10:37 AM Please respond to MQSeries List Pavel, Could you explain how a user could obtain more privilege vis-a-vis the dlq handler? Pavel Tolkachev pavel.tolkachev To: [EMAIL PROTECTED] @DB.COM cc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.AC.AT 09/10/2003 09:28 AM Please respond to MQSeries List Well, denial of service attack is always
Re: Security with Server Connection channels
Hello Rick, Sorry, this will be in reply to your previous mail down the trail (I lost the original); I agree with your last sentence completely. Disabling the channel is not quite the same as writing my messages to other person's queue (from security breach point of view). Disabling channel is more a denial-of-service type of attack. But in general your analogy is valid: one of actual reasons for my conservatism wrt DLQ is that this is another non-protected MQ resource available for modification to any application. (from Unix point of view, DLQ reminds me a file writable to others, and even worse because there is no analog for per-user ulimit or quota). The first such resource is, of course, a QM-QM channel of any type :-) Of course, the situation may be improved with Exits, but it takes a lot of work... Pavel Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 03:38 PM Please respond to MQSeries List How would you decide who, or who isn't an authorized user? The contention is/was that we could have a malicious user, who could be an authorized user as well. Bill Anderson [EMAIL PROTECTED] To: [EMAIL PROTECTED] ITA.AEROcc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.AC.AT 09/10/2003 03:24 PM Please respond to MQSeries List In regard to the dlq, making use of the MCAUSER on a receiver channel might lend a hand (this will not work for client connections). When the MCAUSER on a receiver channel is non blank it behaves much different than a server connection for a client. For a receiver you have to set the authorizations as follows to avoid getting a troublesome 2035: Authorizations needed for queue manager: +inq, +connect, +set, + setall Authorizations needed for destination queue and DLQ: +put and +setall So, on selected receivers, you could block access to the dlq by not doing the +put thing, and still have it available for authorized users. Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 02:22 PM Please respond to MQSeries List I'm not sure I agree with your contention that a DLQ would enable a user to gain more privileges. Also, by not having a DLQ, you could also stop the channel by trying to send a message to a bogus remote queue. This would, in effect, also deny legitimate messages from being sent. Pavel Tolkachev pavel.tolkachev To: [EMAIL PROTECTED] @DB.COM cc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.AC.AT 09/10/2003 01:49 PM Please respond to MQSeries List Well, by default the default dlq handler is running as mqm. One thing the user who is allowed to publish messages can always do is to overflow his queue, deny others access to the dead letter queue (by flooding it as well) and, subject to his knowledge of the dlq rules in effect, and the rules themselves, try to achieve forwarding his or her messages to other queues where s/he does not belong. Pavel Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 10:37 AM Please respond to MQSeries List Pavel, Could you explain how a user could obtain more privilege vis-a-vis the dlq handler? Pavel Tolkachev pavel.tolkachev To: [EMAIL PROTECTED] @DB.COM cc: Sent
Re: Security with Server Connection channels
Thanks Phil, It is good to know you have one. I guess such exits must become a pretty common type of a 3rd-party product for MQ in the next year or so. Before SSL, the generic security purpose exits (Security and Message) had to use their own non-standard ways to encrypt information and exchange credentials, so that there were no standard and they must had been difficult to sell on a horizontal markets. Now things should change... 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 03:58 PM Please respond to MQSeries List Pavel, I actually build a Security Exit to address your concern. It checks either the incoming IP address or the incoming SSLPEER against a list of SSLPEER (Distinguished Names) and/or IP addresses, and then assigns a corresponding user id to the MCAUSER field. The exit can also be used to validate any other channel type as well. With Sender types, however, setting the MCAUSER has no affect, so its necessary to CLOSE the channel if their identity is not on the list. You could always create a new channel for every possible MQClient and hard code the SSLPEER, but what a pain to administer. Phil Pavel Tolkachev pavel.tolkachev@To: [EMAIL PROTECTED] DB.COM cc: Sent by: MQSeriesSubject: Re: Security with Server Connection channels List [EMAIL PROTECTED] n.AC.AT 09/10/2003 02:17 PM Please respond to MQSeries List 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: MQSeriesSubject: 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
Re: Security with Server Connection channels
My new bumper sticker: If DLQs are outlawed then only outlaws will have DLQs -- T.Rob -Original Message- From: Bill Anderson [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 10, 2003 4:00 PM To: [EMAIL PROTECTED] Subject: Re: Security with Server Connection channels Well, I suppose that is more of a business oriented question than a technical one. But, if you delete the dlq completely, its a done deal right, NOBODY can use it because its not there. If you use the MCAUSER to restrict access to some, it is still available for legitimate use. How you choose who can and who cannot talk to it is another issue. Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 03:38 PM Please respond to MQSeries List How would you decide who, or who isn't an authorized user? The contention is/was that we could have a malicious user, who could be an authorized user as well. Bill Anderson [EMAIL PROTECTED] To: [EMAIL PROTECTED] ITA.AEROcc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.AC.AT 09/10/2003 03:24 PM Please respond to MQSeries List In regard to the dlq, making use of the MCAUSER on a receiver channel might lend a hand (this will not work for client connections). When the MCAUSER on a receiver channel is non blank it behaves much different than a server connection for a client. For a receiver you have to set the authorizations as follows to avoid getting a troublesome 2035: Authorizations needed for queue manager: +inq, +connect, +set, + setall Authorizations needed for destination queue and DLQ: +put and +setall So, on selected receivers, you could block access to the dlq by not doing the +put thing, and still have it available for authorized users. Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 02:22 PM Please respond to MQSeries List I'm not sure I agree with your contention that a DLQ would enable a user to gain more privileges. Also, by not having a DLQ, you could also stop the channel by trying to send a message to a bogus remote queue. This would, in effect, also deny legitimate messages from being sent. Pavel Tolkachev pavel.tolkachev To: [EMAIL PROTECTED] @DB.COM cc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.AC.AT 09/10/2003 01:49 PM Please respond to MQSeries List Well, by default the default dlq handler is running as mqm. One thing the user who is allowed to publish messages can always do is to overflow his queue, deny others access to the dead letter queue (by flooding it as well) and, subject to his knowledge of the dlq rules in effect, and the rules themselves, try to achieve forwarding his or her messages to other queues where s/he does not belong. Pavel Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 10:37 AM Please respond to MQSeries List Pavel, Could you explain how a user could obtain more privilege vis-a-vis the dlq handler? Pavel Tolkachev pavel.tolkachev To: [EMAIL PROTECTED] @DB.COM cc: Sent by: Subject: Re: Security with Server Connection channels
Re: Security with Server Connection channels
Phil, Is the source code for this exit available ? Sid -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, 11 September 2003 5:59 AM To: [EMAIL PROTECTED] Subject: Re: Security with Server Connection channels Pavel, I actually build a Security Exit to address your concern. It checks either the incoming IP address or the incoming SSLPEER against a list of SSLPEER (Distinguished Names) and/or IP addresses, and then assigns a corresponding user id to the MCAUSER field. The exit can also be used to validate any other channel type as well. With Sender types, however, setting the MCAUSER has no affect, so its necessary to CLOSE the channel if their identity is not on the list. You could always create a new channel for every possible MQClient and hard code the SSLPEER, but what a pain to administer. Phil Pavel Tolkachev pavel.tolkachev@To: [EMAIL PROTECTED] DB.COM cc: Sent by: MQSeriesSubject: Re: Security with Server Connection channels List [EMAIL PROTECTED] n.AC.AT 09/10/2003 02:17 PM Please respond to MQSeries List 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: MQSeriesSubject: 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
Re: Security with Server Connection channels
You have way too much free time T.Rob! -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Thursday, 11 September 2003 6:37 AM To: [EMAIL PROTECTED] Subject: Re: Security with Server Connection channels My new bumper sticker: If DLQs are outlawed then only outlaws will have DLQs -- T.Rob -Original Message- From: Bill Anderson [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 10, 2003 4:00 PM To: [EMAIL PROTECTED] Subject: Re: Security with Server Connection channels Well, I suppose that is more of a business oriented question than a technical one. But, if you delete the dlq completely, its a done deal right, NOBODY can use it because its not there. If you use the MCAUSER to restrict access to some, it is still available for legitimate use. How you choose who can and who cannot talk to it is another issue. Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 03:38 PM Please respond to MQSeries List How would you decide who, or who isn't an authorized user? The contention is/was that we could have a malicious user, who could be an authorized user as well. Bill Anderson [EMAIL PROTECTED] To: [EMAIL PROTECTED] ITA.AEROcc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.AC.AT 09/10/2003 03:24 PM Please respond to MQSeries List In regard to the dlq, making use of the MCAUSER on a receiver channel might lend a hand (this will not work for client connections). When the MCAUSER on a receiver channel is non blank it behaves much different than a server connection for a client. For a receiver you have to set the authorizations as follows to avoid getting a troublesome 2035: Authorizations needed for queue manager: +inq, +connect, +set, + setall Authorizations needed for destination queue and DLQ: +put and +setall So, on selected receivers, you could block access to the dlq by not doing the +put thing, and still have it available for authorized users. Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 02:22 PM Please respond to MQSeries List I'm not sure I agree with your contention that a DLQ would enable a user to gain more privileges. Also, by not having a DLQ, you could also stop the channel by trying to send a message to a bogus remote queue. This would, in effect, also deny legitimate messages from being sent. Pavel Tolkachev pavel.tolkachev To: [EMAIL PROTECTED] @DB.COM cc: Sent by: Subject: Re: Security with Server Connection channels MQSeries List [EMAIL PROTECTED] en.AC.AT 09/10/2003 01:49 PM Please respond to MQSeries List Well, by default the default dlq handler is running as mqm. One thing the user who is allowed to publish messages can always do is to overflow his queue, deny others access to the dead letter queue (by flooding it as well) and, subject to his knowledge of the dlq rules in effect, and the rules themselves, try to achieve forwarding his or her messages to other queues where s/he does not belong. Pavel Rick Tsujimoto [EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COMcc: Sent by: MQSeries List Subject: Re: Security with Server Connection channels [EMAIL PROTECTED] 09/10/2003 10:37 AM Please respond to MQSeries List Pavel, Could you explain how a user could obtain more privilege vis-a-vis the dlq handler? Pavel Tolkachev
Security with Server Connection channels
Title: Message 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 YoungB I.T. (cs dc) AD (cse) DBAIntranet DeveloperAnalyst / 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 RdWest End, QLD 4101
Re: Client Connection changed to Server Connection
Hi Franklin, In addition to what Stefan said... Since you want the program to connect as a server, all you have to do is compile your program with the server libraries. Ruzi --- Stefan Sievert [EMAIL PROTECTED] wrote: Franklin, if your application is compiled code that is linked with the MQ client libraries, it may run without any error locally to a queue manager if either MQSERVER or MQCHLTAB is defined and available. If they are not, I assume it will just return a reason code of 2059 during MQCONN processing, just like it would on a remote client that isn't set up properly. HTH, Stefan From: franklin dcosta [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Client Connection changed to Server Connection Date: Wed, 28 May 2003 14:58:15 +0100 HI Friends, A small question for you all, if an application connected as a client , is moved , to connect as a server, will it give an error and what type of error? Regards, Franklin __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html 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 _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail 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
Re: Client Connection changed to Server Connection
Thanks Stefan and Ruzi for your answer, but the problem here is , if the application which has ALREADY SUCCESFULLY connected as a client, wants to now connect as a server , will it cause an error and what type of error Regards, Franklin Hi Franklin, In addition to what Stefan said... Since you want the program to connect as a server, all you have to do is compile your program with the server libraries. Ruzi --- Stefan Sievert [EMAIL PROTECTED] wrote: Franklin, if your application is compiled code that is linked with the MQ client libraries, it may run without any error locally to a queue manager if either MQSERVER or MQCHLTAB is defined and available. If they are not, I assume it will just return a reason code of 2059 during MQCONN processing, just like it would on a remote client that isn't set up properly. HTH, Stefan From: franklin dcosta [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Client Connection changed to Server Connection Date: Wed, 28 May 2003 14:58:15 +0100 HI Friends, A small question for you all, if an application connected as a client , is moved , to connect as a server, will it give an error and what type of error? Regards, Franklin __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html 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 _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail 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 __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html 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
Client Connection changed to Server Connection
HI Friends, A small question for you all, if an application connected as a client , is moved , to connect as a server, will it give an error and what type of error? Regards, Franklin __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html 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
Re: Client Connection changed to Server Connection
For a c/c++ application you must re-link the application if you want to change access from client to server. If you move a client to a server machine where the client portion is not installed you will get an error. Francois van der Merwe Senior IT Specialist: IBM MQSeries Certified Specialist, Solutions Expert Developer IBM, Cape Town, South Africa +27 (0)82 556 9467 / +27 (0)21 402 5597 [EMAIL PROTECTED] franklin dcosta [EMAIL PROTECTED]To: [EMAIL PROTECTED] M cc: Sent by: MQSeriesSubject: Client Connection changed to Server Connection List [EMAIL PROTECTED] N.AC.AT 28/05/2003 15:58 Please respond to MQSeries List HI Friends, A small question for you all, if an application connected as a client , is moved , to connect as a server, will it give an error and what type of error? Regards, Franklin __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html 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
Re: Client Connection changed to Server Connection
Franklin, if your application is compiled code that is linked with the MQ client libraries, it may run without any error locally to a queue manager if either MQSERVER or MQCHLTAB is defined and available. If they are not, I assume it will just return a reason code of 2059 during MQCONN processing, just like it would on a remote client that isn't set up properly. HTH, Stefan From: franklin dcosta [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Client Connection changed to Server Connection Date: Wed, 28 May 2003 14:58:15 +0100 HI Friends, A small question for you all, if an application connected as a client , is moved , to connect as a server, will it give an error and what type of error? Regards, Franklin __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html 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 _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail 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
Re: Security Exit for Server-Connection channel
Redd, Error code 127 from MS documentation is 127 The specified procedure could not ERROR_PROC_NOT_FOUND be found. The most likely cause of this, I would think, is that the procedure MyFunc is not exported from the DLL. I would check your DEF file (or whatever mechanism you use). It should not be necessary to restart the QM on these types of failures. Just change the DLL and restart the channel, Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley 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
Security Exit for Server-Connection channel
Hi All I am facing a problem with implementing a Security Exit for Server-Connection channel. When i am trying to put the message it throws an error message: *01/12/2003 16:41:48 AMQ6175: The system could not dynamically load the library c:\mqseries\sec.dll. The system return code was 127. The queue manager will continue without this module. EXPLANATION: This message applies to Windows NT and Windows 2000 systems only. The dynamically loadable file c:\mqseries\sec.dll failed to load correctly due toan internal error. The MQSeries error recording routine has been called. ACTION: Check that the file has not been corrupted then use the standard facilities supplied with your system to record the problem identifier, and to save the generated output files. Contact your IBM support center. Do not discard these files until the problem has been resolved. --- 01/12/2003 16:41:48 AMQ9535: User exit not valid. EXPLANATION: Channel program 'EDEALER.APP.CHANNEL' ended because user exit 'c:\mqseries\sec.dll(MyFunc)' is not valid.ACTION:Ensure that the user exit is specified correctly in the channel definition, and that the user exit program is correct and available. -** I tried restarting the MQSeries server as well as the machine also. But it was no different. I searched the MQSeries archives for the solution, but it was not of a much help. Anyone faced this problem before? My environment is Windows NT and i have written code in C++ (compiler is Visual Studio 5.0) Thanks in advance, Regards Redd 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
How I can start the server connection channel in MQseries5.2 on winNT operating system?
How I can start the server connection channel in MQseries5.2 on winNT operating system? Thanks Regards, senthil 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
Re: How I can start the server connection channel in MQseries5.2 on winNT operating system?
By connecting from a CLIENT. Windy How I can start the server connection channel in MQseries5.2 on winNT operating system? Thanks Regards, senthil 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
Re: How I can start the server connection channel
You also need a listener service on the host monitoring the port that the clients will be calling on. -Will At 04:29 PM 6/27/2002 +0100, Andrew Miller wrote: By connecting from a CLIENT. Windy How I can start the server connection channel in MQseries5.2 on winNT operating system? Thanks Regards, senthil 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
Re: How I can start the server connection channel
And by the way, Senthil -- please fix your computer's clock so that your emails don't keep appearing at the top of my mailbox... :-P -Will At 11:09 PM 11/6/2003 +0530, Karthikeyan Senthilnathan wrote: How I can start the server connection channel in MQseries5.2 on winNT operating system? Thanks Regards, senthil 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
Re: Limit on Server Connection
See the MAXCHANNELS parameter in the qm.ini file (Check out the System Admin and Client manuals). Ingi.Hong@BERGENB To: [EMAIL PROTECTED] RUNSWIG.COM cc: Sent by: Subject: Limit on Server Connection MQSERIES@akh-wien .ac.at 06/06/2002 05:37 PM Please respond to MQSERIES Hi MQers, Can anyone tell where the limit or the maximum number of server-connections a Queue manager allows is specified? How can I change it to nomax? Thanks in advance, Ingi Hong AmerisourceBergen Corporation Technical Support Capacity Planning Email: [EMAIL PROTECTED] Fax: 714) 704-7031 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
Server Connection
Hello, I have MQ5.2 running on Win2000. From an MQ cilent an application opens up a server-connection channel per an MQI request -- this is a load testing appliocation -- causing many server-connection channels running simultaneously. I can see this from MQ Explorer. Soon MQ can not handle the load any more -- I do not know how many server-connection channels are running -- poping the message up into the EventViewer like, maximum number of channels reached. It also says the number of permitted channels is a configurable parameter in the Queue manager configuration file. Does anyone know how to configure this? Advice will be greatly appreciated. Thanks, Ingi Hong AmerisourceBergen Corporation Technical Support Capacity Planning Email: [EMAIL PROTECTED] Office: 714) 385-4331 Fax: 714) 704-7031 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
Re: Server Connection
Ingi, You would require to update your qm.ini file to add following lines in channel stanza: CHANNELS: MaxChannels=256 MaxActiveChannels=256 Hope that will help. -Arif -Original Message- From: Ingi Hong [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 10:04 AM To: [EMAIL PROTECTED] Subject: Server Connection Hello, I have MQ5.2 running on Win2000. From an MQ cilent an application opens up a server-connection channel per an MQI request -- this is a load testing appliocation -- causing many server-connection channels running simultaneously. I can see this from MQ Explorer. Soon MQ can not handle the load any more -- I do not know how many server-connection channels are running -- poping the message up into the EventViewer like, maximum number of channels reached. It also says the number of permitted channels is a configurable parameter in the Queue manager configuration file. Does anyone know how to configure this? Advice will be greatly appreciated. Thanks, Ingi Hong AmerisourceBergen Corporation Technical Support Capacity Planning Email: [EMAIL PROTECTED] Office: 714) 385-4331 Fax: 714) 704-7031 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 message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. 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
Re: Server Connection
Open your MQSeries Services panel, RIGHT CLICK on the Queue Manager and click on the PROPERTIES tab then click on CHANNELS tab and there you will find the MAX CHANNELS and MAX ACTIVE CHANNELS . Emile Kearns Software Futures -Original Message- From: Ingi Hong [mailto:[EMAIL PROTECTED]] Sent: 07 June 2002 04:04 To: [EMAIL PROTECTED] Subject: Server Connection Hello, I have MQ5.2 running on Win2000. From an MQ cilent an application opens up a server-connection channel per an MQI request -- this is a load testing appliocation -- causing many server-connection channels running simultaneously. I can see this from MQ Explorer. Soon MQ can not handle the load any more -- I do not know how many server-connection channels are running -- poping the message up into the EventViewer like, maximum number of channels reached. It also says the number of permitted channels is a configurable parameter in the Queue manager configuration file. Does anyone know how to configure this? Advice will be greatly appreciated. Thanks, Ingi Hong AmerisourceBergen Corporation Technical Support Capacity Planning Email: [EMAIL PROTECTED] Office: 714) 385-4331 Fax: 714) 704-7031 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
