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 10000, 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 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: MQSeries Subject: 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. *** Credit Lyonnais **************************************************** This e-mail contains confidential information or information belonging to Credit Lyonnais and is intended solely for the addressees. The unauthorized disclosure, use, dissemination or copying (either whole or partial) of this e-mail, or any information it contains, is prohibited. E-mails are susceptible to alteration and their integrity cannot be guaranteed. Credit Lyonnais shall not be liable for this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Credit Lyonnais in the Americas: Credit Lyonnais Bank New York Branch, Credit Lyonnais Americas Services Inc., Credit Lyonnais Rouse (USA) Ltd., and Credit Lyonnais Securities (USA) Inc. *** Credit Lyonnais **************************************************** 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
