Or CommerceQuest's ProtectMQ. --- "David C. Partridge" <[EMAIL PROTECTED]> wrote: > 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
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.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
