Re: MQIPT remote client
Title: Message Hi Navin, I am copying part of the email that I had sent to someone a while ago pertaining to MQ security on Windows. This is what I had understood from MQ manuals and some postings on the internet. I couldn't try this myself though. I hope this helps. === Let's consider set-up for only the development box to start with. This development box that will host the MQ Development server will be a windows server and will be part of some domain. The domain will also have some boxes (machines) which will act as the primary domain controller (PDC) and secondary domain controller (SDC). On Windows - to administer MQ, the user must be a member of a group named 'mqm' or should be a member of the 'Administrators' group. 'mqm' group is created, if one does not exist, automatically at the time of installation. Now the user who needs to administer can either log on to the dev. box locally or via the network. This user can get the administration rights if he is a member of the mqm or Administrators group of the local machine. But he also needs to be granted the administration rights if he logs on via some other machine on the network. The following steps shouldenable this user (or more users, as needed) to administer MQ on the dev. box irrespective of where he logs on from. Let's name this user USER1 a. delete any local groups named 'mqm' (without the quotes) on the dev. box b. on the PDC, create a global group named 'MQAdmGrp' (group that will have the administration rights to the dev. MQ server) c. add USER1 (from the domain, USER1 may be qualified with the domain name, e.g. [EMAIL PROTECTED]) to this group. You can also add more users who need the administration rights d. on the dev. box, create a local group named 'mqm' e. add theglobal group 'MQAdmGrp' to this local group 'mqm' created on the dev. box (this should grant access to all users in MQAdmGrp to administer the dev. MQ server f. if you want to add a local user of the dev. box then you can add that user either to the local group 'mqm' created in step 'd' above or the 'Administrators' group of the dev. box g. for access control to various MQ objects, you can use the 'setmqaut' command. You can create user groups on the PDC for different access levels. One such group, say for application developers, could be 'devMQUsers', and then use the 'setmqaut' command on the dev. MQ server to grant access to this group on the queue manager, queues, processes, etc. === Thanks and best regards, Urvesh. -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Navin ValiSent: Thursday, September 16, 2004 3:46 PMTo: [EMAIL PROTECTED]Subject: MQIPT remote client Hi All, Have implemented MQIPT so can filter IPs and at the same time implemented Security Exit in MQIPt which makes it possible for user to connect to certain CHANNELS only. Implemented CHANNEL level Security Exits in MQ server which work in tandem with the Security Exits at client side. HandShake, UserName transfer and then Password transfer and then UserName and Password authentication based on the NT secuirty mechanism i.e. user has to exist in Windows. And then the user can place the message in the desired queue. But the problem is the user coming from the remote client has to be there in the MQM group. And as soon as you add the user in MQM group he gets all the MQI rights and MQAdmin rights like create, drop, change etc. which is wrong. I want to give the user only rights for GET on certain queue and PUT in another queue. Queue level rights. Trying to use SETMQAUT and DSPMQAUT but of no use as user can't place the message in he is not in MQM group and as soon as you enter him in MQM group he has all the rights which cannot be altered using the above said commands. Any thoughts !!! Thanks in Advance Navin ALL-NEW Yahoo! Messenger - all new features - even more fun!
Re: MQIPT remote client
Title: Message In step g, if you plan on restricting groups on what MQ objects they have access to, you cannot put those groups in the mqm group. Anyone in the mqm group has 100% full authority, and you cannot take away any of it with setmqaut. Put these types of groups and/or IDs not in the mqm group but somewhere else, and then add the rights they need, since they will have none to begin with, assuming you didn't put them in a group that already had some MQ authorities set. -Original Message-From: Urvesh Bipin Shah [mailto:[EMAIL PROTECTED]Sent: Thursday, September 16, 2004 8:20 AMTo: [EMAIL PROTECTED]Subject: Re: MQIPT remote client Hi Navin, I am copying part of the email that I had sent to someone a while ago pertaining to MQ security on Windows. This is what I had understood from MQ manuals and some postings on the internet. I couldn't try this myself though. I hope this helps. === Let's consider set-up for only the development box to start with. This development box that will host the MQ Development server will be a windows server and will be part of some domain. The domain will also have some boxes (machines) which will act as the primary domain controller (PDC) and secondary domain controller (SDC). On Windows - to administer MQ, the user must be a member of a group named 'mqm' or should be a member of the 'Administrators' group. 'mqm' group is created, if one does not exist, automatically at the time of installation. Now the user who needs to administer can either log on to the dev. box locally or via the network. This user can get the administration rights if he is a member of the mqm or Administrators group of the local machine. But he also needs to be granted the administration rights if he logs on via some other machine on the network. The following steps shouldenable this user (or more users, as needed) to administer MQ on the dev. box irrespective of where he logs on from. Let's name this user USER1 a. delete any local groups named 'mqm' (without the quotes) on the dev. box b. on the PDC, create a global group named 'MQAdmGrp' (group that will have the administration rights to the dev. MQ server) c. add USER1 (from the domain, USER1 may be qualified with the domain name, e.g. [EMAIL PROTECTED]) to this group. You can also add more users who need the administration rights d. on the dev. box, create a local group named 'mqm' e. add theglobal group 'MQAdmGrp' to this local group 'mqm' created on the dev. box (this should grant access to all users in MQAdmGrp to administer the dev. MQ server f. if you want to add a local user of the dev. box then you can add that user either to the local group 'mqm' created in step 'd' above or the 'Administrators' group of the dev. box g. for access control to various MQ objects, you can use the 'setmqaut' command. You can create user groups on the PDC for different access levels. One such group, say for application developers, could be 'devMQUsers', and then use the 'setmqaut' command on the dev. MQ server to grant access to this group on the queue manager, queues, processes, etc. === Thanks and best regards, Urvesh. -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Navin ValiSent: Thursday, September 16, 2004 3:46 PMTo: [EMAIL PROTECTED]Subject: MQIPT remote client Hi All, Have implemented MQIPT so can filter IPs and at the same time implemented Security Exit in MQIPt which makes it possible for user to connect to certain CHANNELS only. Implemented CHANNEL level Security Exits in MQ server which work in tandem with the Security Exits at client side. HandShake, UserName transfer and then Password transfer and then UserName and Password authentication based on the NT secuirty mechanism i.e. user has to exist in Windows. And then the user can place the message in the desired queue. But the problem is the user coming from the remote client has to be there in the MQM group. And as soon as you add the user in MQM group he gets all the MQI rights and MQAdmin rights like create, drop, change etc. which is wrong. I want to give the user only rights for GET on certain queue and PUT in another queue. Queue level rights. Trying to use SETMQAUT and DSPMQAUT but of no use as user can't place the message in he is not in MQM group and as soon as you enter him in MQM group he has all the rights which cannot be altered using the above said commands. Any thoughts !!! Thanks in Advance Navin ALL-NEW Yahoo! Messenger - all new features - even more fun! This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information
Re: MQIPT remote client
Title: Message 'mqm' group for MQ administrators only and creation of separate groups for different levels of access to MQ objects is what I had meant. Please excuse me if it was confusing. -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (ISD, IT)Sent: Thursday, September 16, 2004 6:10 PMTo: [EMAIL PROTECTED]Subject: Re: MQIPT remote client In step g, if you plan on restricting groups on what MQ objects they have access to, you cannot put those groups in the mqm group. Anyone in the mqm group has 100% full authority, and you cannot take away any of it with setmqaut. Put these types of groups and/or IDs not in the mqm group but somewhere else, and then add the rights they need, since they will have none to begin with, assuming you didn't put them in a group that already had some MQ authorities set. -Original Message-From: Urvesh Bipin Shah [mailto:[EMAIL PROTECTED]Sent: Thursday, September 16, 2004 8:20 AMTo: [EMAIL PROTECTED]Subject: Re: MQIPT remote client Hi Navin, I am copying part of the email that I had sent to someone a while ago pertaining to MQ security on Windows. This is what I had understood from MQ manuals and some postings on the internet. I couldn't try this myself though. I hope this helps. === Let's consider set-up for only the development box to start with. This development box that will host the MQ Development server will be a windows server and will be part of some domain. The domain will also have some boxes (machines) which will act as the primary domain controller (PDC) and secondary domain controller (SDC). On Windows - to administer MQ, the user must be a member of a group named 'mqm' or should be a member of the 'Administrators' group. 'mqm' group is created, if one does not exist, automatically at the time of installation. Now the user who needs to administer can either log on to the dev. box locally or via the network. This user can get the administration rights if he is a member of the mqm or Administrators group of the local machine. But he also needs to be granted the administration rights if he logs on via some other machine on the network. The following steps shouldenable this user (or more users, as needed) to administer MQ on the dev. box irrespective of where he logs on from. Let's name this user USER1 a. delete any local groups named 'mqm' (without the quotes) on the dev. box b. on the PDC, create a global group named 'MQAdmGrp' (group that will have the administration rights to the dev. MQ server) c. add USER1 (from the domain, USER1 may be qualified with the domain name, e.g. [EMAIL PROTECTED]) to this group. You can also add more users who need the administration rights d. on the dev. box, create a local group named 'mqm' e. add theglobal group 'MQAdmGrp' to this local group 'mqm' created on the dev. box (this should grant access to all users in MQAdmGrp to administer the dev. MQ server f. if you want to add a local user of the dev. box then you can add that user either to the local group 'mqm' created in step 'd' above or the 'Administrators' group of the dev. box g. for access control to various MQ objects, you can use the 'setmqaut' command. You can create user groups on the PDC for different access levels. One such group, say for application developers, could be 'devMQUsers', and then use the 'setmqaut' command on the dev. MQ server to grant access to this group on the queue manager, queues, processes, etc. === Thanks and best regards, Urvesh. -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Navin ValiSent: Thursday, September 16, 2004 3:46 PMTo: [EMAIL PROTECTED]Subject: MQIPT remote client Hi All, Have implemented MQIPT so can filter IPs and at the same time implemented Security Exit in MQIPt which makes it possible for user to connect to certain CHANNELS only. Implemented CHANNEL level Security Exits in MQ server which work in tandem with the Security Exits at client side. HandShake, UserName transfer and then Password transfer and then UserName and Password authentication based on the NT secuirty mechanism i.e. user has to exist in Windows. And then the user can place the message in the desired queue. But the problem is the user coming from the remote client has to be there in the MQM group. And as soon as you add the user in MQM group he gets all the MQI rights and MQAdmin rights like create, drop, change
Re: MQIPT Trace Question
Title: MQIPT Trace Question I had opened an ETR with IBM about the format of the trace files from MQIPT earlier this year. I was told the format is "undocumented". If you do find some documentation, please let me (us)know. -Original Message-From: Harmeson, Steve (Newport News) [mailto:[EMAIL PROTECTED]Sent: Friday, July 23, 2004 7:44 AMTo: [EMAIL PROTECTED]Subject: MQIPT Trace Question We are running MQIPT 1.31 (WebSphere internet pass-thru )on a W2k box between two other servers and in the iptmain.trc file of MQIPT I see this message: Time: 13:45:22.160 2004.07.19 Class: com.ibm.mq.ipt.ConnectionLogger Method: logConnection Thread ID: ConnThd for Route 1443-2 Logger: Main Trace Command 172.16.246.152 PING 1443-2 --- com.ibm.mq.ipt.ConnectionLogger.moveFilesIfNecessary (ConnThd for Route 1443-2) 13:45:22.175 My question is about the moveFilesIfNecessary text, what does it mean and where can I find info on the other messages in this file. Thanks for any help. Steve Harmeson Enterprise System Support Northrop Grumman Newport News IIS This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies.
Re: MQIPT Trace Question
These are usually undocumented because by the time you figure it out, IBM has changed it. Potkay, Peter M (ISD, IT) [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 07/23/2004 08:21 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: MQIPT Trace Question I had opened an ETR with IBM about the format of the trace files from MQIPT earlier this year. I was told the format is undocumented. If you do find some documentation, please let me (us) know. -Original Message- From: Harmeson, Steve (Newport News) [mailto:[EMAIL PROTECTED] Sent: Friday, July 23, 2004 7:44 AM To: [EMAIL PROTECTED] Subject: MQIPT Trace Question We are running MQIPT 1.31 (WebSphere internet pass-thru )on a W2k box between two other servers and in the iptmain.trc file of MQIPT I see this message: Time:13:45:22.160 2004.07.19 Class: com.ibm.mq.ipt.ConnectionLogger Method: logConnection Thread ID: ConnThd for Route 1443-2 Logger: Main Trace Command 172.16.246.152 PING 1443-2 --- com.ibm.mq.ipt.ConnectionLogger.moveFilesIfNecessary (ConnThd for Route 1443-2) 13:45:22.175 My question is about the moveFilesIfNecessary text, what does it mean and where can I find info on the other messages in this file. Thanks for any help. Steve Harmeson Enterprise System Support Northrop Grumman Newport News IIS This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
Re: MQIPT
Wonderful!!!, Thank you so much for your reply. I had the same setting up for my current project but wasn't really sure about my sender channel from Q Mgr say QM1(1411) to IPT(1418). Once again, I appreciate your help and quick response. I just love this forum, this is so amazing. Khan --- Potkay, Peter M (PLC, IT) [EMAIL PROTECTED] wrote: QM1 and MQIPT are both running on ServerA QM1 is listening on port 1414, perhaps for channels coming from QM2 on ServerB. The MQIPT service is listening on (pick a number) port 1418. The MQIPT config file says that any MQ traffic that comes in on this port gets forwarded over to some other server/port combo, lets say ServerX/port. ServerX has either a QM listening on port, or perhaps there is another MQIPT on port. QM1 then has a SENDER channel to QM99. But the conname for channel QM1.QM99 is not ServerX(port). It is Server1(port1418). The channel will then go from QM1 on ServerA to MQIPT on ServerA(1418) to whatever is listening on ServerX(). -Original Message- From: Hashim Khan [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 5:20 PM To: [EMAIL PROTECTED] Subject: Re: MQIPT Hi There, I'm trying to understand the sender channel setup going from my qmgr to IPT. Q Mgr and IPT both are on the same server. Thanx in advance for your precious time and suggestions --- Darren Douch [EMAIL PROTECTED] wrote: Trying to save myself some digging around any views on the pros / cons of MQIPT vs. a full blown queue manager for supporting secure MQ connections over the internet? And are there any views (or documents) about the performance / scalability of MQIPT? Thanks folks. Darren. __ Do you Yahoo!? Yahoo! Search - Find what you re looking for faster http://search.yahoo.com 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, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. 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 __ Do you Yahoo!? Yahoo! Search - Find what you re looking for faster http://search.yahoo.com 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: MQIPT
Hi There, I'm trying to understand the sender channel setup going from my qmgr to IPT. Q Mgr and IPT both are on the same server. Thanx in advance for your precious time and suggestions --- Darren Douch [EMAIL PROTECTED] wrote: Trying to save myself some digging around any views on the pros / cons of MQIPT vs. a full blown queue manager for supporting secure MQ connections over the internet? And are there any views (or documents) about the performance / scalability of MQIPT? Thanks folks. Darren. __ Do you Yahoo!? Yahoo! Search - Find what you re looking for faster http://search.yahoo.com 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: MQIPT
QM1 and MQIPT are both running on ServerA QM1 is listening on port 1414, perhaps for channels coming from QM2 on ServerB. The MQIPT service is listening on (pick a number) port 1418. The MQIPT config file says that any MQ traffic that comes in on this port gets forwarded over to some other server/port combo, lets say ServerX/port. ServerX has either a QM listening on port, or perhaps there is another MQIPT on port. QM1 then has a SENDER channel to QM99. But the conname for channel QM1.QM99 is not ServerX(port). It is Server1(port1418). The channel will then go from QM1 on ServerA to MQIPT on ServerA(1418) to whatever is listening on ServerX(). -Original Message- From: Hashim Khan [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 5:20 PM To: [EMAIL PROTECTED] Subject: Re: MQIPT Hi There, I'm trying to understand the sender channel setup going from my qmgr to IPT. Q Mgr and IPT both are on the same server. Thanx in advance for your precious time and suggestions --- Darren Douch [EMAIL PROTECTED] wrote: Trying to save myself some digging around any views on the pros / cons of MQIPT vs. a full blown queue manager for supporting secure MQ connections over the internet? And are there any views (or documents) about the performance / scalability of MQIPT? Thanks folks. Darren. __ Do you Yahoo!? Yahoo! Search - Find what you re looking for faster http://search.yahoo.com 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, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. 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: MQIPT
I luckily haven't been hit by any of this, but I am ready. I came up with this from reading the manuals and this list server. Special thanks goes to T.Rob, as some of these tips are his. -Original Message- From: Awerbuch, David [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 24, 2004 9:26 AM To: [EMAIL PROTECTED] Subject: Re: MQIPT Peter, Is this rather exhaustive list based on your own experience, or have you simply acquired bobbee's paranoia? Either way, this email certainly provides valuable security items that everyone needs to keep in mind. I never quite thought about all of these possibilities. A client has a trusted vendor coming directly into one of their systems. After having read your missive, I believe now is a good time for me to propose a new, intermediate, more secure MQ manager for their vendor to connect through. Thanks, Dave A. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 11:17 AM To: [EMAIL PROTECTED] Subject: Re: MQIPT The other company could: Try and start 1000 connections to your listener at once, crashing him. Now all your channels to the hub are down. (You should have a dedicated listener for each outside company.) Try and send command messages to your SYSTEM.ADMIN.COMMAND.QUEUE, messing with you infrastructure. (You should set the MCAUSER on the RCVR, and give that ID the bare minimum access only to the queues it needs to get to (this includes authority to the QM as well as the DLQ). Maybe even stop the command server (do you really want to do that o your internal Hun QM though?)). Try and send messages to another application's queue. (See above) Try and send 100 meg message to a queue. They fill up your disk, crashing you Hub QM. (You should set the max message length parameter on your RCVR channel to the smallest # that makes sense for the app) Try and send 999,999,999 10 byte messages as fast as they can, filling up your disk. (You should insure they can only put messages to their queues, and set their queues to a small max queue depth. If that fills up, or if they start putting to a queue other than their own, causing 2035s, the DLQ starts filling up. You don't want your Hub's DLQ full! So you set the Message Retry Counts and Intervals on the RCVR channel. Now when a message would go to the DLQ, it will, but only after (Message Retry Counts X Intervals) seconds. This throttles it way back. I use 10 and 1, so in this scenario, my DLQ would get 1 message every 100 seconds. This effectively puts a cork on the bad guys attempt, or the looping program. Monitor your DLQ, and you will have plenty of time to stop the problem, with evidence in the DLQ. You should use remote queue defs on the hub, that then point to the final destination queues on one of your spoke QMs. And then only give authority to put to these remote queue defs. If you don't do this, but instead rely on Name resolution, you must give this ID access to the XMIT queue that goes to the spoke QM. If you don't then set authority on the Spoke's RCVR MCA, they could mess with that QM. If that spoke QM is used by lots of other apps internally, do you really want to mess with the authorities on that channel? Way easier to use the remote queue defs on the initial QM that they connect to. (They will then act like a filter, insuring messages only go to the spoke QM's queues you want) Even with all of the above, you need SSL to verify who the other side is. MQIPT has SSL, and will verify who the other side is. Regular SSL on the actual channel does the same thing I suppose. But MQIPT also masks your Hub's server and port#, since the other guy's channels point at the IP / port that MQIPT is listening on, which then forwards the message to your QM. I guess this is somewhat valuable. But maybe you want multiple channels, and only want to set SSL once. Well, MQIPT will give you that tunnel, but beware, because now ALL your channels can be accessed if they can guess the name. Now you have to lock them down. Otherwise, it is very easy for them to connect to SYSTEM.ADMIN.SVRCONN as mqm, or create a SNDR on their side called SYSTEM.DEF.RCVR, and connect to your default RCVR. Any channels they can guess the name of, have to be protected. Seriously reconsider using your Hub as the Qm that talks to the other company. Can you prove they can't guess the name of one of you real spoke QMs channel names? You can't lock them all down. Even with all the above precautions, can you be 100% certain they can't come up with a way to damage the QM they connect to? I can't. Do you want to explain to your boss that they crashed the Hub QM, or that they crashed their own dedicated Edge QM, leaving your Hub up? -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 6:19 AM To: [EMAIL PROTECTED] Subject: Re: MQIPT Thanks for the responses. We have an MQ hub on our 'customer' network
Re: MQIPT
Peter, Is this rather exhaustive list based on your own experience, or have you simply acquired bobbee's paranoia? Either way, this email certainly provides valuable security items that everyone needs to keep in mind. I never quite thought about all of these possibilities. A client has a trusted vendor coming directly into one of their systems. After having read your missive, I believe now is a good time for me to propose a new, intermediate, more secure MQ manager for their vendor to connect through. Thanks, Dave A. -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 11:17 AM To: [EMAIL PROTECTED] Subject: Re: MQIPT The other company could: Try and start 1000 connections to your listener at once, crashing him. Now all your channels to the hub are down. (You should have a dedicated listener for each outside company.) Try and send command messages to your SYSTEM.ADMIN.COMMAND.QUEUE, messing with you infrastructure. (You should set the MCAUSER on the RCVR, and give that ID the bare minimum access only to the queues it needs to get to (this includes authority to the QM as well as the DLQ). Maybe even stop the command server (do you really want to do that o your internal Hun QM though?)). Try and send messages to another application's queue. (See above) Try and send 100 meg message to a queue. They fill up your disk, crashing you Hub QM. (You should set the max message length parameter on your RCVR channel to the smallest # that makes sense for the app) Try and send 999,999,999 10 byte messages as fast as they can, filling up your disk. (You should insure they can only put messages to their queues, and set their queues to a small max queue depth. If that fills up, or if they start putting to a queue other than their own, causing 2035s, the DLQ starts filling up. You don't want your Hub's DLQ full! So you set the Message Retry Counts and Intervals on the RCVR channel. Now when a message would go to the DLQ, it will, but only after (Message Retry Counts X Intervals) seconds. This throttles it way back. I use 10 and 1, so in this scenario, my DLQ would get 1 message every 100 seconds. This effectively puts a cork on the bad guys attempt, or the looping program. Monitor your DLQ, and you will have plenty of time to stop the problem, with evidence in the DLQ. You should use remote queue defs on the hub, that then point to the final destination queues on one of your spoke QMs. And then only give authority to put to these remote queue defs. If you don't do this, but instead rely on Name resolution, you must give this ID access to the XMIT queue that goes to the spoke QM. If you don't then set authority on the Spoke's RCVR MCA, they could mess with that QM. If that spoke QM is used by lots of other apps internally, do you really want to mess with the authorities on that channel? Way easier to use the remote queue defs on the initial QM that they connect to. (They will then act like a filter, insuring messages only go to the spoke QM's queues you want) Even with all of the above, you need SSL to verify who the other side is. MQIPT has SSL, and will verify who the other side is. Regular SSL on the actual channel does the same thing I suppose. But MQIPT also masks your Hub's server and port#, since the other guy's channels point at the IP / port that MQIPT is listening on, which then forwards the message to your QM. I guess this is somewhat valuable. But maybe you want multiple channels, and only want to set SSL once. Well, MQIPT will give you that tunnel, but beware, because now ALL your channels can be accessed if they can guess the name. Now you have to lock them down. Otherwise, it is very easy for them to connect to SYSTEM.ADMIN.SVRCONN as mqm, or create a SNDR on their side called SYSTEM.DEF.RCVR, and connect to your default RCVR. Any channels they can guess the name of, have to be protected. Seriously reconsider using your Hub as the Qm that talks to the other company. Can you prove they can't guess the name of one of you real spoke QMs channel names? You can't lock them all down. Even with all the above precautions, can you be 100% certain they can't come up with a way to damage the QM they connect to? I can't. Do you want to explain to your boss that they crashed the Hub QM, or that they crashed their own dedicated Edge QM, leaving your Hub up? -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 6:19 AM To: [EMAIL PROTECTED] Subject: Re: MQIPT Thanks for the responses. We have an MQ hub on our 'customer' network, and are now looking to allow other users connect to us over the Internet. VPN doesn't appeal (to me) because a, we'd have to spend money, install and configure it, and b, so would everyone that wants to come in. So MQ/SSL, with an exit or two for good measure is the probable way we will go. That just leaves the question of whether the Internet
Re: MQIPT
Thanks for the responses. We have an MQ hub on our 'customer' network, and are now looking to allow other users connect to us over the Internet. VPN doesn't appeal (to me) because a, we'd have to spend money, install and configure it, and b, so would everyone that wants to come in. So MQ/SSL, with an exit or two for good measure is the probable way we will go. That just leaves the question of whether the Internet connections come into a new (Internet-facing) hub qmgr, or just through IPT. IPT seems like it might be simpler to put in and administer... but apart from that I'm struggling to see any big pros/cons. Thanks Darren - Original Message - From: Bill Anderson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 19, 2004 9:30 PM Subject: Re: MQIPT Funny you should ask. As I write this, I am in the middle of setting up MQIPT on my LINUX workstation to test it out. It looks easy enough, but we will see. Right off the bat I got an error from an install shell script complaining that it tried to install an LDAP application that conflicted wit an already installed package. When I get it fired up, I'll let ya know how it goes. The main alternative is VPN. Because it is by nature, a secure tunnel, SSL is not required at the MQ level. But at least for an enterprise implementation with extremely sensitive data, a cheap VPN solution may not be secure enough. I have used VPN to remotely administrate MQ in the past, but I really don't know allot about it technically. One of the network security folks here told me just today that while the price range is quite wide, $10,000 + would not be unheard of to implement a VPN solution. Of course MQIPT is free, and what's a couple of servers to put it on? $5,000 ? Personally, I like the MQIPT solution better (probably because I understand it better). But on the other hand if a company has non-MQ reasons to support a VPN into there private LAN, why not use it for MQ access as well? performance possibly? Anyway, good luck I have an MQIPT server to set up Cheers Bill Anderson SITA Atlanta, GA Standard Messaging Engineering WebSphere MQ Service Owner 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Darren Douch [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: MQIPT List [EMAIL PROTECTED] N.AC.AT 02/19/2004 02:41 PM Please respond to MQSeries List Trying to save myself some digging around any views on the pros / cons of MQIPT vs. a full blown queue manager for supporting secure MQ connections over the internet? And are there any views (or documents) about the performance / scalability of MQIPT? Thanks folks. Darren. 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: MQIPT
The other company could: Try and start 1000 connections to your listener at once, crashing him. Now all your channels to the hub are down. (You should have a dedicated listener for each outside company.) Try and send command messages to your SYSTEM.ADMIN.COMMAND.QUEUE, messing with you infrastructure. (You should set the MCAUSER on the RCVR, and give that ID the bare minimum access only to the queues it needs to get to (this includes authority to the QM as well as the DLQ). Maybe even stop the command server (do you really want to do that o your internal Hun QM though?)). Try and send messages to another application's queue. (See above) Try and send 100 meg message to a queue. They fill up your disk, crashing you Hub QM. (You should set the max message length parameter on your RCVR channel to the smallest # that makes sense for the app) Try and send 999,999,999 10 byte messages as fast as they can, filling up your disk. (You should insure they can only put messages to their queues, and set their queues to a small max queue depth. If that fills up, or if they start putting to a queue other than their own, causing 2035s, the DLQ starts filling up. You don't want your Hub's DLQ full! So you set the Message Retry Counts and Intervals on the RCVR channel. Now when a message would go to the DLQ, it will, but only after (Message Retry Counts X Intervals) seconds. This throttles it way back. I use 10 and 1, so in this scenario, my DLQ would get 1 message every 100 seconds. This effectively puts a cork on the bad guys attempt, or the looping program. Monitor your DLQ, and you will have plenty of time to stop the problem, with evidence in the DLQ. You should use remote queue defs on the hub, that then point to the final destination queues on one of your spoke QMs. And then only give authority to put to these remote queue defs. If you don't do this, but instead rely on Name resolution, you must give this ID access to the XMIT queue that goes to the spoke QM. If you don't then set authority on the Spoke's RCVR MCA, they could mess with that QM. If that spoke QM is used by lots of other apps internally, do you really want to mess with the authorities on that channel? Way easier to use the remote queue defs on the initial QM that they connect to. (They will then act like a filter, insuring messages only go to the spoke QM's queues you want) Even with all of the above, you need SSL to verify who the other side is. MQIPT has SSL, and will verify who the other side is. Regular SSL on the actual channel does the same thing I suppose. But MQIPT also masks your Hub's server and port#, since the other guy's channels point at the IP / port that MQIPT is listening on, which then forwards the message to your QM. I guess this is somewhat valuable. But maybe you want multiple channels, and only want to set SSL once. Well, MQIPT will give you that tunnel, but beware, because now ALL your channels can be accessed if they can guess the name. Now you have to lock them down. Otherwise, it is very easy for them to connect to SYSTEM.ADMIN.SVRCONN as mqm, or create a SNDR on their side called SYSTEM.DEF.RCVR, and connect to your default RCVR. Any channels they can guess the name of, have to be protected. Seriously reconsider using your Hub as the Qm that talks to the other company. Can you prove they can't guess the name of one of you real spoke QMs channel names? You can't lock them all down. Even with all the above precautions, can you be 100% certain they can't come up with a way to damage the QM they connect to? I can't. Do you want to explain to your boss that they crashed the Hub QM, or that they crashed their own dedicated Edge QM, leaving your Hub up? -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 6:19 AM To: [EMAIL PROTECTED] Subject: Re: MQIPT Thanks for the responses. We have an MQ hub on our 'customer' network, and are now looking to allow other users connect to us over the Internet. VPN doesn't appeal (to me) because a, we'd have to spend money, install and configure it, and b, so would everyone that wants to come in. So MQ/SSL, with an exit or two for good measure is the probable way we will go. That just leaves the question of whether the Internet connections come into a new (Internet-facing) hub qmgr, or just through IPT. IPT seems like it might be simpler to put in and administer... but apart from that I'm struggling to see any big pros/cons. Thanks Darren - Original Message - From: Bill Anderson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 19, 2004 9:30 PM Subject: Re: MQIPT Funny you should ask. As I write this, I am in the middle of setting up MQIPT on my LINUX workstation to test it out. It looks easy enough, but we will see. Right off the bat I got an error from an install shell script complaining that it tried to install an LDAP application that conflicted wit an already installed package. When I
Re: MQIPT
Funny you should ask. As I write this, I am in the middle of setting up MQIPT on my LINUX workstation to test it out. It looks easy enough, but we will see. Right off the bat I got an error from an install shell script complaining that it tried to install an LDAP application that conflicted wit an already installed package. When I get it fired up, I'll let ya know how it goes. The main alternative is VPN. Because it is by nature, a secure tunnel, SSL is not required at the MQ level. But at least for an enterprise implementation with extremely sensitive data, a cheap VPN solution may not be secure enough. I have used VPN to remotely administrate MQ in the past, but I really don't know allot about it technically. One of the network security folks here told me just today that while the price range is quite wide, $10,000 + would not be unheard of to implement a VPN solution. Of course MQIPT is free, and what's a couple of servers to put it on? $5,000 ? Personally, I like the MQIPT solution better (probably because I understand it better). But on the other hand if a company has non-MQ reasons to support a VPN into there private LAN, why not use it for MQ access as well? performance possibly? Anyway, good luck I have an MQIPT server to set up Cheers Bill Anderson SITA Atlanta, GA Standard Messaging Engineering WebSphere MQ Service Owner 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Darren Douch [EMAIL PROTECTED]To: [EMAIL PROTECTED] OM cc: Sent by: MQSeriesSubject: MQIPT List [EMAIL PROTECTED] N.AC.AT 02/19/2004 02:41 PM Please respond to MQSeries List Trying to save myself some digging around any views on the pros / cons of MQIPT vs. a full blown queue manager for supporting secure MQ connections over the internet? And are there any views (or documents) about the performance / scalability of MQIPT? Thanks folks. Darren. 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: MQIPT: Enalbe SSL communication
I wrote an article some months ago on this subject, if you can read french it is here : http://consulting.demey.org/faq.php HTH, LMD. Date sent: Mon, 8 Dec 2003 09:59:08 -0500 Send reply to: MQSeries List [EMAIL PROTECTED] From: Usha Suryadevara [EMAIL PROTECTED] Subject:MQIPT: Enalbe SSL communication To: [EMAIL PROTECTED] Hi all, I have an MQ 5.3 client-server environment setup on windows platform. I am using MQIPT and am trying to enable communication via SSL. I was trying to create a self signed certificate using the KeyMan utility (its a key management utility that comes with the MQIPT installation). However i am unable to do this part. It works when i use the sample .pfx files that come with the installation. Any information regarding this issue is highly appreciated. Thanks Usha PS: I want to use SSL only for encrypting (not for client/server authentication) the data. I would like to change the world, but they wont tell me the source code 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 -- Luc-Michel Demey - Freelance EAI Consultant Paris / France Tel. : +33 6 08 755 655 http://consulting.demey.org/ - lmd at demey dot org 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: MQIPT
thanks Ron. I somehow missed that part. - Usha At 02:02 PM 9/24/2003 -0700, you wrote: I think you need to run the mqiptservice.exe to install the mqipt as a service. Check out Chapter 13 of the manual. Ron --- Usha Suryadevara [EMAIL PROTECTED] wrote: Guys, Documentation says MQIPT runs as a service, and i assumed its a windows service. It actually runs as a service where a command prompt sits on your desktop all the time the service is running. Is there a way i can make this service run in the background or run as a windows service? Thanks Usha 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 __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com 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: MQIPT
I think you need to run the mqiptservice.exe to install the mqipt as a service. Check out Chapter 13 of the manual. Ron --- Usha Suryadevara [EMAIL PROTECTED] wrote: Guys, Documentation says MQIPT runs as a service, and i assumed its a windows service. It actually runs as a service where a command prompt sits on your desktop all the time the service is running. Is there a way i can make this service run in the background or run as a windows service? Thanks Usha 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 __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com 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: MQIPT through a firewall - part II
Hi Phil, Thanks for the reply. I suspected as much but I have to say I'm surprised there hasn't been more interest in this feature. Oh well... While you're here ;-) I've found that the second part of the chain isn't working either. I've set up the Apache Rewrite as specified in the manual and I believe this is working but I'm getting 2059 when I try to connect my MQ client. The remote MQIPT trace shows that I'm getting through Apache and the HTTP header looks ok but shortly after this I get a Java exception in the remote MQIPT: Time: 12:23:43.231 2003.09.03 Class: com.ibm.mq.ipt.ConnectionThread Method: callerToResponder Thread ID: ConnThd for Route 61414-0 Logger: TraceLogger 61414 Waiting for next message from caller... Time: 12:23:43.581 2003.09.03 Class: com.ibm.mq.ipt.ConnectionThread Method: run Thread ID: ConnThd for Route 61414-0 Logger: TraceLogger 61414 IOException in run() : , p1=java.io.EOFException -- com.ibm.mq.ipt.ConnectionThread.closeAllConnections (ConnThd for Route 61414-0) 12:23:43.581 I've got trace=5 so I don't know how to get any more details about this. Any help would be appreciated. Cheers, Paul -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Phil Blake Sent: 02 September 2003 20:52 To: [EMAIL PROTECTED] Subject: MQIPT through a firewall Hi Paul, Sorry, MQIPT doesn't support proxy authentication. I think you're only the second person to ask for this feature. All I can say is that it's on the requirements list for the next release of MQIPT if and when there is one. Sorry I can't be more exact. Phil Blake - Message from Paul Meekin [EMAIL PROTECTED] on Tue, 2 Sep 2003 10:01:42 +0100 - Subject: MQIPT through a firewall I'm trying to get an MQ connection going through a firewall in pretty much the same configuration as the Apache Rewrite scenario as detalied in the MQIPT manual. As you've probably already guessed - it's not working. My HTTP proxy requires basic authentication. Here is the result from the trace: Time: 09:49:48.711 2003.09.02 Class: com.ibm.mq.ipt.ConnectionThread Method: getHTTPHeader Thread ID: ConnThd for Route 62000-0 Logger: TraceLogger 62000 HTTP/1.1 407 Proxy authentication required Proxy-Authenticate: NTLM Proxy-Authenticate: Basic realm=172.30.60.2 Content-Length: 503 Content-Type: text/html Time: 09:49:48.711 2003.09.02 Class: com.ibm.mq.ipt.ConnectionThread Method: createHTTPConnection Thread ID: ConnThd for Route 62000-0 Logger: TraceLogger 62000 MQCPE058 CONNECT request to myhost.mydomain.com(80) through ewprxy2(8080) failed Anyone know if it is possible to pass a userid/password to the HTTP proxy? By the way, the actual setup is: MQ Client - Local MQIPT - HTTP Proxy - (firewall) - Apache HTTP Server - MQIPT - Target QMgr Cheers, Paul Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive * This e-mail is from Energis Communications Ltd, 185 Park Street, London, SE1 9DY, United Kingdom, No: 2630471. This e-mail is confidential to the addressee and may be privileged. The views expressed are personal and do not necessarily reflect those of Energis. If you are not the intended recipient please notify the sender immediately by calling our switchboard on +44 (0) 20 7206 and do not disclose to another person or use, copy or forward all or any of it in any form. * 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
