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
