Sorry,
I thought that was part of my quote at first glance. Yes, if the
channels are not protected anyone can connect to any inbound channel. The
total solution is to use an exit or SSL to restrict the inbound connections to
the appropriate channel, AND the MCAUSER to enforce the ID restrictions.
Using one or the other doesn't work.
It
bears noting that the exit or SSL used must be placed on the protected
internal channels and is optional on the external facing channel if you
only have one. A common mistake is placing the exit on the
external-facing channel and leaving the internal-facing ones
unprotected.
--
T.Rob
-----Original Message-----
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 12:37 PM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewallThanks T.Rob.What about the channel question I had below. Am I missing something there?-----Original Message-----
From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 12:23 PM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewallNo, it just means you need to specify all the parameters. If you run a saveqmgr it prints out runmqsc commands suitable for use on a QMgr with no SYSTEM.DEF* objects. Use these as templates for your queue definitions if you need to add or change anything. Make sure you run saveqmgr on the same server or at least one with a matching version of MQ.-- T.Rob-----Original Message-----
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2003 10:08 AM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewallT.Rob wrote:"Every time I bring this up, people always reply that you can accomplish the same thing with an exit or MCAUSER. My answer to that is that you cannot restrict traffic to a specific channel. For example, if you define XYZ.RCVR with MCAUSER('xyz'), there is nothing to prevent ABC Corp from connecting to it."If ABC corp connects to XYZ.RCVR, and XYZ.RCVR has a MCA USer Identifier set to 'xyz', then all the messages coming across this channel will have xyz, even ABC's messages. How is that different than if the ABC got to XYZ.RCVR through another listner / port? If ABC connects XYZ.RCVR over port 2222, where a listener is running as def, aren't the messages still put as xyz, not def, xyz is in the MCAUSER?Also, you mentioned "we also delete all SYSTEM.DEF* objects". I tried deleting SYSTEM.DEFAULT.LOCAL.QUEUE on a dummy QM, and now I cant create any queues, which I suppose is the goal. But does that meaning that from this point forward, I can never create any more local queues on this QM?-----Original Message-----
From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 4:44 PM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewallPeter,I've not used MQIPT so I don't know what security concerns it addresses - or introduces. Since I work for a bank, I always start with the assumption that my DMZ servers are targets of attack and I try to nail them down as tight as possible. In my shop we would do that last paragraph regardless of any assumed security provided by MQIPT, our firewall or private circuits.And that's just the beginning. In the DMZ we also delete all SYSTEM.DEF* objects, set up LOCALADDR to bind the internal-facing channels to internal-facing NICs and run security exits (or SSL where available). We also never use a SVR channel in the DMZ or define a SVRCONN for external use. As a rule, the Command Server and Trigger Monitor are turned off unless specifically required. If we do run a trigger monitor, it runs under a low-privileged ID. All channels use MCAUSER set to a low-privileged ID. The QMgr runs under an ID other than mqm and mqm is removed from the mqm group. UserIDs in the DMZ are never authorized to SET*. All of these configurations address one or more specific vulnerabilities and when you apply all of them in combination, it is VERY difficult to get admin access to the QMgr from outside or to hijack queues and channels for other than their intended use.Incidentally, you mentioned a dedicated QMgr "for outbound messaging (to other companies)" and I notice that's plural. Are you hosting interfaces to more than one company on the same QMgr? In that case, I would DEFINITELY want to lock down each interface under a separate ID. Can you imagine the fallout if company A used your MQ interface to maliciously attack Company B? If your naming standards make it easy to guess channel names and queue names based on customer name or ID, hijacking someone else's channel or queue is not so farfetched. Hell, you might even do it by accident when copying MQSC scripts from one customer to another and miss the RNAME in a QREMOTE or something. If you made this mistake with the listener running as mqm, nothing would stop the messages from going to the wrong queue or out to the wrong customer.-- T.Rob-----Original Message-----
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 3:59 PM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewallT.Rob, in regards to your last paragraph, is that still necessary ifA. Your queue manager is a dedicated one just for outbound messaging (to other companies) sitting in the DMZandB. MQIPT sits between your DMZ queue manager and any outside companies?(There are very specific firewall rules between the DMZ queue manager and the internal queue manager inside of the internal firewall that it connects to.)-----Original Message-----
From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 12:19 PM
To: [EMAIL PROTECTED]
Subject: Re: Penetrating an outbound firewallDoug,We are using direct MQ connections with firewall rules as specified in MA86This has been working fine for us except that servers with dual NICs or virtual IP addresses (our Veritas clusters), the socket would sometimes bind to a different address under MQ pre-5.3 and be blocked by the firewall. Prior to 5.3 we had to set up rules for the physical AND virtual addresses since the binding was unspecified. The LOCALADDR field has really simplified things. We have tried setting up rules for entire subnets but have since switched to using a set of rules for each point-to-point connection. Although there are more rules, there are less surprises when you change one.Might I also suggest that you run a listener (not inetd) for external traffic that is different from your internal traffic. This way, you can shut down the external connection without impacting your internal network. If you have multiple business partners connecting to the same QMgr, run a different listener for each. Then you can disable one without impacting the others.If you are really security conscious, run the listeners under a low-privileged ID. For example, if you have connections to XYZ Corp and ABC Corp, you can create UserIDs xyz and abc and put them into groups xyz and abc, respectively. Then start listeners under each ID. This will allow you to set up authorizations on the queues such that traffic from ABC and XYZ cannot end up on each other's queues or, worse yet, on your Command Queue. Every time I bring this up, people always reply that you can accomplish the same thing with an exit or MCAUSER. My answer to that is that you cannot restrict traffic to a specific channel. For example, if you define XYZ.RCVR with MCAUSER('xyz'), there is nothing to prevent ABC Corp from connecting to it. For that matter, there is nothing to prevent ABC Corp from connecting to SYSTEM.DEF.SVRCONN or any other channel unless you run exits on ALL of them or use SSL on ALL of them. Running the listeners under low-privileged IDs allows you to lock down a specific path from the firewall all the way down to specific queues.Regards,-- T.Rob-----Original Message-----
From: Pierson, Doug (ITD) [mailto:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 10:30 AM
To: [EMAIL PROTECTED]
Subject: Penetrating an outbound firewallHi MQers,
Does anyone have any experience with sending MQ messages outbound through a firewall that restricts outbound traffic? The traffic needs to be delivered to numerous destination servers. Are you using MQ-IPT? If so, are you using multiple ports to define multiple routes and sending the traffic to IPT instances deployed at each of the target servers? Or, is all of your traffic sent to a single IPT instance outside of the firewall using a single route? From there, queue name resolution can be used to direct it to the true destination server with the messages in MQ protocol.
The goal of the firewall administrator is to restrict us to minimal port usage. We see the restriction to a single port using IPT to be to costly in terms of performance. The traffic volume is significant. I'm also aware of MQ5.3's introduction of the LOCLADDR channel attribute to restrict outbound traffic to a single port or range of ports.
Any comments or feedback would be much appreciated.
Thanks,
Doug Pierson
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.
