We have a situation where we have multiple queue managers that support WAS and Tuxedo applications doing request/reply with a vendor's queue manager. Up until now we have only a handful of queue managers connecting to the vendor, but the setup is difficult. We have to get NAT'd IP addresses established on the firewall for each internal server, then have to wait several weeks for the vendor to get channels and there firewall setup and hope nobody changes an IP address.
What we are considering doing is setting up an "edge-of-network" queue manager that is the only one connected to the vendor (actually probably 2 separate servers) this way our internal queue managers could connect to a clustered queue that is a remote definition to the vendor's request queue (load balance to intermediate server). This way we only have to establish connectivity with the vendor w/ 2 servers. It seems like a good idea, but has anyone tried this before and have any suggestions? I can think of at least 1 issue regarding the reply queue name. The reply message will have to be routed back to the correct internal server. We could code the intermediate servers queue manager name and reply queue in the message so the vendor automatically routes it back to a "correct" reply-to-queue. Then the intermediate reply-to-queue would be a remote definition of the real internal queue managers reply-to-queue. This would be ok, except that we would have to manage a set of intermediate reply-to-queue/remote queues. Can anyone think of a better way to do it so everything is auto-defined? Thanks in advance for any input. Brian M. McCarty USAA, Senior Systems Programmer 210.913.1678 MQ/WMQI Specialist/Solutions Expert e-business Solution Advisor/Designer/Technologist -----Original Message----- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 2:27 AM To: [EMAIL PROTECTED] Subject: Re: MQSeries in DMZ I'm in San Francisco for the Advanced Clustering class this week so maybe I'll have a different view by Friday. At the moment, however, I'd have to say that clustering adds even more security considerations into the mix. It does channel auto-definition by default and the cluster channels need all the same exits that we've already discussed. If you put an exit on a cluster receiver of your AppServer so it can talk to the DMZ, then every other server that uses the same cluster receiver needs the same exit! Furthermore, it stores a lot of data about your trusted network on its local repository so this becomes an obvious target for intruders. I'm a little leary about using a clustered DMZ node but, as I said, I may change my mind by Friday. I'll have to ask the instructor for comments. -- T.Rob -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 7:53 AM To: [EMAIL PROTECTED] Subject: Re: MQSeries in DMZ T.Bob, You have raised a good point in using the MQ server in the DMZ as a pass through and having the data processing on an internal server, perhaps a cluster might achieve this, the source queues and processing of the clear text data could occur on the internal server and the encrypted data resides in the DMZ server, then using SSL to harden the channel and using a security exit for authentication as well as firewall routing rules would give you a reasonably secure environment. I am only suggesting the cluster to give a bit of scope for expansion and perhaps easier management. When I try it here at work sometime in the next few months, I'll let everyone know how practical it is. Sid -----Original Message----- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Saturday, 7 June 2003 12:01 AM To: [EMAIL PROTECTED] Subject: Re: MQSeries in DMZ David, To expand a little further, the ideal situation is that encryption/signing of messages occurs at the endpoints whereas connections need to be authenticated point-to-point. So you are right that some kind of app-to-app encryption is best here. SSL only authenticates or encrypts from point-to-point and only on the wire. The messages are in plaintext on the queue making them vulnerable as they hop through the DMZ. However, firewall IP filtering does not qualify as authentication. SSL between the DMZ and the client site hardens that communication path so I still believe SSL is appropriate here. Of course, I work for a bank and take a pretty conservative approach to external connections. As far as storing keys in the DMZ, my objection is that no processing or manipulation of the messages should occur in the DMZ. They should just pass through. Keys for point-to-point authentication (SSL for example) are necessary, of course. But as far as manipulating the messages, the whole point of the DMZ is that you don't trust it, right? If you did, you wouldn't need a DMZ, you'd just put your app server right next to the external firewall and forget about it. So if we don't trust the DMZ, the last thing we want to do is store the keys to the castle in it. But as I said, my employer requires me to take a rather conservative view of these things. Your mileage may vary. -- T.Rob -----Original Message----- From: David C. Partridge [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 5:39 AM To: [EMAIL PROTECTED] Subject: Re: MQSeries in DMZ Nice summary. SSL is (probably) not appropriate here for encryption purposes, and an application to application encryption product such as Primeur DSMQ E2E (preferred by me anyway, but then I'm biased, as I designed it), Candle MQSecure, or Tivoli AMBI is more appropriate. Alternatives to SSL could also be considered such as channel exit based solutions (strange we do that too!). As far as the issue of storing keys on the DMZ machine is concerned, I wouldn't be worried if the keys were stored in an HSM. Cheers Dave -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Wyatt, T. Rob Sent: 05 June 2003 19:00 To: [EMAIL PROTECTED] Subject: Re: MQSeries in DMZ Tim, Make sure you use MQ 5.3 in the DMZ. One of the new features is a channel attribute that binds the channel to a particular local IP address. Your DMZ will have two addresses we are concerned with - the IP address your trusted network sees, and the IP address the world sees. You will also have two categories of channel: customer-facing channels and internal-facing channels. By specifying the LOCLADDR, you can insure that your internal-facing channels are not hijacked by external users. For example, assume your DMZ server has a RCVR or RQSTR channel called APPSVR.DMZ with no exit. One of your customers could create a SDR or SVR channel called APPSVR.DMZ and try to start it. Without a LOCLADDR specified, the channel would bind to the external-facing IP and the firewall would allow the connection. On the other hand, if you set the LOCLADDR attribute to your internal-facing IP address, the external firewall will disallow the connection. There are a LOT of other considerations. For example, if the data is sensitive and encrypted, you don't want to store the keys on the DMZ. It would be better to have the messages signed/encrypted at either end and have them pass the DMZ unaltered. Also, IP filtering as provided at the firewall is strong but not 100% reliable. It is possible to spoof an IP address and it is possible that an intrusion attempt could come from a trusted business partner. If your listeners are running as mqm, they can potentially be hijacked. Better to run your listeners as low-privileged IDs. Use different listeners and ports for internal-facing and external-facing connections. In fact, use different listeners for each customer if you want to be really safe. Finally, consider the implications of multiple clients using the same QMgr. If one client can put messages onto another client's remote queue, your company may be partially liable for any damages that are caused. You can enforce isolation of each client's traffic if each client has its own listener, running under its own ID, listening on its own port; and each client has its own channel pair, its own UserID in the MCAUSER, and its own remote queues authorized to that UserID. This is just a quick review. If you really want to harden your DMZ (and I hope you do by now!) There are many additional options available in MQ configuration, exits, architecture, etc. It all depends on how valuable and sensitive the messages are and how far you want to go to protect them. -- T.Rob -----Original Message----- From: Madsen, Timothy [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: MQSeries in DMZ Hello, We have external partners who need to connect to our MQSeries. So, we could put an MQSeries server in our DMZ and let those external people connect to that MQ and then have the DMZ MQ connect to our internal MQ. We can configure our firewall (Cisco Pix) to only let MQ appropriate ports/protocols pass from the internet to the DMZ MQ server. However, we would still be allowing **anybody** on the internet to send messages to our MQSeries in our DMZ. We are working with a small list of partners - they are not anonymous. So - from this two questions: 1) Would this be considered a fairly secure configuration - from the standpoint of a hacker trying to get into our MQ box and crash it or access OS services? 2) What is a standard method whereby we could allow our external partners to send MQ messages - but not allow other people on the internet to send MQ messages to our DMZ MQ server? Thanks. Tim. 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 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 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
