Re: Penetrating an outbound firewall
Title: Penetrating an outbound firewall 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Thanks 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall No, 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 AMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.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 , 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Peter, 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 compa
Re: Penetrating an outbound firewall
I like to make my own templets that incorporate any "non default" object attributes. For instance, I have a template called TEMPLATE.XMIT.QUEUE that is all set up to be a triggered transmit queue. When I want a transmit queue (and all of mine are triggered) in the script I say DEFINE QLOCAL(Q NAME) LIKE(TEMPLATE.XMIT.QUEUE) and I have a triggered transmit queue. Now I can have the folks in ops build the definitions, and they don't have to know anything about triggering a transmit queue. It works well Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: RTFORD.COM> Subject: Re: Penetrating an outbound firewall Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 10/15/2003 12:37 PM Please respond to MQSeries List Thanks 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 firewall No, 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 firewall T.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 , 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 firewall Peter, 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
Re: Penetrating an outbound firewall
Peter has described the problem well. That said, here is my two cents In part what we are concerned with is the difference between authorization and authentication. Making use of the MCAUSER attribute of a channel is important to security, but is does NOTHING to validate that the connecting application is a trusted partner. OK, what's a boy to do? a security exit is the only way to Authenticate a user (unless your implementing SSL I guess). I have implemented one at our site here in Atlanta, that is quite simple, and needs only to run on receiver side. All of the users of my queue managers are external customers, so asking them to develop software is turf to do. So customers who want extra security need only change existing programs to send a user ID and password. How that data is send depends on what language the sending program is written in. Our current implementation is JAVA specific. Once the security exit "authenticates" the user during the MQCONN call, it returns control back to the MCA and the user id for that channel session is set to a value of my choice via the MCAUSER attribute of the channel. But all of this gets more administratively intense than some companies may care to deal with. About half of my users are client connections. While MQ would be quite happy to service all of them via one simple Server Connection Channel, for security reason EVERYONE gets a dedicated SVRCONN channel, so that each of them has a unique user id. So now the very name of the cannel its self becomes part of your security implementation. If somebody has ill intent, they have to access your channel to get to your queue. If they don't know the channel name, well, they have there work cut out for them don't they. And of course, a security exit goes a long way here. This also adds to your system admin problems. MQ assumes each value in the MCAUSER field is defined as a valid user at the operating system level. If is does not exist there, your going to fall on your sword. Making use of the MCAUSER attribute of a SVRCONN channel is about as straight forward as life gets in IT. Making use of it on a receiver channel is another story. One that's not told in any manual I have read. It has to do with What authorizations you need to give to the user id in question. For a SVRCONN channel, giving them a +connect on the queue manager and a +put / get on the queue is suffice. On a receiver, you need to do the following: On the queue manager object +connect +inq +set +setall On a local queue object +put / get (what ever) +setall On the dead letter queue +put +setall the dead letter thing really surprised me, but, that's the way it works! As for deleting will known objects such as SYSTEM.DEFAULT.* to improve security, it is unnecessary and inconvenient. The inconvenient part becomes obvious about the first time you try to create a new object that depends on the SYSTEM.DEFAULT* as a template. The unnecessary part is that setting the MCAUSER attribute of the SYSTEM.DEF.RECEIVER to a value that is not defined on the underlying OS is sufficient to stop a hack. Ok, that was more like a nickel than two cents, but it is a subject that I hold near and dear to my heart. Folks that claim MQ has weak security features have not milked the cow enough! Cheers Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: RTFORD.COM> Subject: Re: Penetrating an outbound firewall Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 10/15/2003 10:07 AM Please respond to MQSeries List T.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 , 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 go
Re: Penetrating an outbound firewall
As this discussion has become a nice try to at least name all aspects of MQ security, I would like to mention another two: 1. Dead letter queue handler rules that may allow messages to go to the queue where they do not belong. 2. The problem of administering several queue managers belonging to the different organizational units who do not trust each other with all QMs running on a single big box. Just my 2 c Pavel -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 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
Re: Penetrating an outbound firewall
Title: Message That is what I suspected, but didn't know if I was missing anything. Thanks for all your post related to security. They are helpful. I am putting together a doc on MQ Security for our company, and your ideas are good for some of our more vulnerable servers (DMZ ones). -Original Message-From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED]Sent: Wednesday, October 15, 2003 12:47 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Peter, Working at a bank, my answer to that is that I'm going to strip away all non-essential parts of MQ where external connectivity is concerned. I can, through automation, just as easily recreate the command queue on demand as I can start the command server. It's an extra line of code and second or so of response time. On the other hand, I never have to explain to an auditor why the command queue was there. If the project manager wants to keep any security-related items, (s)he needs to spec it out and sign off on it and then any audit issues are still not my problem. As is so often the case, project issues - even those related to security - often turn out to be technically simple but politically driven. That's not to say there are no valid technical reasons for taking the extreme approach. Every single hurdle I put up in front of an intruder slows them down that much more but more importantly, it also increases the fingerprints left behind. Any intruder can start the command server and recreate the queue in under a minute but it will take much longer to erase the evidence from the MQ logs AND the system logs since we now have both an MQ internal command and some system-level commands. The more forensic evidence I force the intruder to create, the harder it is to erase all of it. I'm going to force an intruder to make as many extra keystrokes and stay online as long as possible. -- T.Rob -Original Message-From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]Sent: Wednesday, October 15, 2003 10:39 AMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.Rob, What do you think of just stopping the command server? My thinking is if they have access to the box to start the command server locally, they can just as easily use runmqsc to create the queue. True, it is an extra step, but does it buy us anything really to delete the command queue on top of stopping the command server? As a side note, does anyone know of an MQ class just for security. I am writing up a doc for Security for MQ at our company, and man, this is a subject unto itself! -Original Message-From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED]Sent: Wednesday, September 10, 2003 8:27 AMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall You can't. Without going into too much detail, you would need an agent that doesn't rely on the command server, a command server that used a different queue, or you would have to define the queue and start the command server each time. These options may seem like a royal pain but then the whole purpose is to make it hard to administer the QMgr by building significant hurdles for a malicious user to overcome. With appropriate automation, none of these are particularly burdensome for the legitimate admin team. -- T.Rob -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]Sent: Tuesday, September 09, 2003 8:47 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.Rob, If you delete the SYSTEM.ADMIN.COMMAND.QUEUE how do you send command messages ?... sorry if this appears to be a stupid question. Sid -Original Message-From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Saturday, 6 September 2003 6:44 AMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Peter, 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
Re: Penetrating an outbound firewall
Luc-Michel, SSL and MCAUSER address two completely different aspects of security. Whereas SSL will authenticate the remote node, it does not prevent that node from addressing messages to the command queue or anywhere else they should not go. MCAUSER addresses this vulnerability and should be considered even where SSL is in use. In many cases, vendors and service bureaus have not upgraded to 5.3 and SSL is not an option. In the absence of SSL, channel exits address the authentication problem. Any general discussion of MQ security would need to consider playing around with MCAUSER, channel exits, firewalls, etc. -- T.Rob -Original Message- From: Luc-Michel Demey [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 12:17 PM To: [EMAIL PROTECTED] Subject: Re: Penetrating an outbound firewall > T.Rob, > What do you think of just stopping the command server? My thinking > is if > they have access to the box to start the command server locally, > they can just as easily use runmqsc to create the queue. True, it is > an extra step, but does it buy us anything really to delete the > command queue on top of stopping the command server? > > > > > As a side note, does anyone know of an MQ class just for security. I > am writing up a doc for Security for MQ at our company, and man, > this is a subject unto itself! > > Hi, I have done extensive testing about security, hacking and so on, on Queue Managers hosted on Windows and Unix boxes. If you want to protect your QM from external attacks, throught channels, the answer is SSL. Definitively. You can play with MCAUSER, channels exits, firewalls, but ... After applying the CSD, MQ5.3 SSL support works pretty well and is able to secure in a decent way your QM from externam attacks. If you want more (in-queue encryption), have a look at MQ Extended Security Edition 5.3, who includes Policy Director. HTH, Luc-Michel -- Luc-Michel Demey - Freelance EAI Consultant Paris / France Tel. : +33 6 08 755 655 http://consulting.demey.org/ - lmd at demey dot org 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
Re: Penetrating an outbound firewall
Title: Message Peter, Working at a bank, my answer to that is that I'm going to strip away all non-essential parts of MQ where external connectivity is concerned. I can, through automation, just as easily recreate the command queue on demand as I can start the command server. It's an extra line of code and second or so of response time. On the other hand, I never have to explain to an auditor why the command queue was there. If the project manager wants to keep any security-related items, (s)he needs to spec it out and sign off on it and then any audit issues are still not my problem. As is so often the case, project issues - even those related to security - often turn out to be technically simple but politically driven. That's not to say there are no valid technical reasons for taking the extreme approach. Every single hurdle I put up in front of an intruder slows them down that much more but more importantly, it also increases the fingerprints left behind. Any intruder can start the command server and recreate the queue in under a minute but it will take much longer to erase the evidence from the MQ logs AND the system logs since we now have both an MQ internal command and some system-level commands. The more forensic evidence I force the intruder to create, the harder it is to erase all of it. I'm going to force an intruder to make as many extra keystrokes and stay online as long as possible. -- T.Rob -Original Message-From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]Sent: Wednesday, October 15, 2003 10:39 AMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.Rob, What do you think of just stopping the command server? My thinking is if they have access to the box to start the command server locally, they can just as easily use runmqsc to create the queue. True, it is an extra step, but does it buy us anything really to delete the command queue on top of stopping the command server? As a side note, does anyone know of an MQ class just for security. I am writing up a doc for Security for MQ at our company, and man, this is a subject unto itself! -Original Message-From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED]Sent: Wednesday, September 10, 2003 8:27 AMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall You can't. Without going into too much detail, you would need an agent that doesn't rely on the command server, a command server that used a different queue, or you would have to define the queue and start the command server each time. These options may seem like a royal pain but then the whole purpose is to make it hard to administer the QMgr by building significant hurdles for a malicious user to overcome. With appropriate automation, none of these are particularly burdensome for the legitimate admin team. -- T.Rob -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]Sent: Tuesday, September 09, 2003 8:47 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.Rob, If you delete the SYSTEM.ADMIN.COMMAND.QUEUE how do you send command messages ?... sorry if this appears to be a stupid question. Sid -Original Message-From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Saturday, 6 September 2003 6:44 AMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Peter, 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
Re: Penetrating an outbound firewall
Title: Penetrating an outbound firewall Thanks 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall No, 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 AMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.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 , 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Peter, 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.Rob, in regards to you
Re: Penetrating an outbound firewall
SSL will protect you from people you don't know from breaking in. You are always sure of who the other side is with SSL. I does nothing when the trusted guy on the other side decides to behave badly. That is where all the other tricks come into play. SSL in combination with all the other methods is the way to go I suppose. -Original Message- From: Luc-Michel Demey [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 12:17 PM To: [EMAIL PROTECTED] Subject: Re: Penetrating an outbound firewall > T.Rob, > What do you think of just stopping the command server? My thinking > is if > they have access to the box to start the command server locally, > they can just as easily use runmqsc to create the queue. True, it is > an extra step, but does it buy us anything really to delete the > command queue on top of stopping the command server? > > > > > As a side note, does anyone know of an MQ class just for security. I > am writing up a doc for Security for MQ at our company, and man, > this is a subject unto itself! > > Hi, I have done extensive testing about security, hacking and so on, on Queue Managers hosted on Windows and Unix boxes. If you want to protect your QM from external attacks, throught channels, the answer is SSL. Definitively. You can play with MCAUSER, channels exits, firewalls, but ... After applying the CSD, MQ5.3 SSL support works pretty well and is able to secure in a decent way your QM from externam attacks. If you want more (in-queue encryption), have a look at MQ Extended Security Edition 5.3, who includes Policy Director. HTH, Luc-Michel -- Luc-Michel Demey - Freelance EAI Consultant Paris / France Tel. : +33 6 08 755 655 http://consulting.demey.org/ - lmd at demey dot org 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 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. 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
Re: Penetrating an outbound firewall
Title: Penetrating an outbound firewall No, 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 AMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.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 , 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Peter, 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.Rob, in regards to your last paragraph, is that still necessary if A. Your queue manager is a dedicated one just for outbound messaging (to other companies) sitting in the DMZ and B. 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 conne
Re: Penetrating an outbound firewall
> T.Rob, > What do you think of just stopping the command server? My thinking > is if > they have access to the box to start the command server locally, > they can just as easily use runmqsc to create the queue. True, it is > an extra step, but does it buy us anything really to delete the > command queue on top of stopping the command server? > > > > > As a side note, does anyone know of an MQ class just for security. I > am writing up a doc for Security for MQ at our company, and man, > this is a subject unto itself! > > Hi, I have done extensive testing about security, hacking and so on, on Queue Managers hosted on Windows and Unix boxes. If you want to protect your QM from external attacks, throught channels, the answer is SSL. Definitively. You can play with MCAUSER, channels exits, firewalls, but ... After applying the CSD, MQ5.3 SSL support works pretty well and is able to secure in a decent way your QM from externam attacks. If you want more (in-queue encryption), have a look at MQ Extended Security Edition 5.3, who includes Policy Director. HTH, Luc-Michel -- Luc-Michel Demey - Freelance EAI Consultant Paris / France Tel. : +33 6 08 755 655 http://consulting.demey.org/ - lmd at demey dot org 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
Re: Penetrating an outbound firewall
Thanks Sam. That did it. -Original Message- From: Sam Garforth [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 11:08 AM To: [EMAIL PROTECTED] Subject: Re: Penetrating an outbound firewall I think you should be able to create queues using the LIKE parameter. Sam --- "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote: > T.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 , > 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 firewall > > > Peter, > > 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 firewall > > > T.Rob, in regards to your last paragraph, is that > still necessary if > > A. Your queue manager is a dedicated one just for > outbound messaging (to > other companies) sitting in the DMZ > > and > > B. 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 ma
Re: Penetrating an outbound firewall
Thanks I have seen these very informative docs. They don't address T.Rob's suggestion of deleting the queue altogether. I am curious if it is a benificial extra step or not. -Original Message- From: Sam Garforth [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 11:48 AM To: [EMAIL PROTECTED] Subject: Re: Penetrating an outbound firewall Try http://www.sjg-enterpriseintegration.com/oamsecurity.asp and http://www.sjg-enterpriseintegration.com/closingmqholes.asp --- "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote: > T.Rob, > What do you think of just stopping the command > server? My thinking is if > they have access to the box to start the command > server locally, they can > just as easily use runmqsc to create the queue. > True, it is an extra step, > but does it buy us anything really to delete the > command queue on top of > stopping the command server? > > > > > As a side note, does anyone know of an MQ class just > for security. I am > writing up a doc for Security for MQ at our company, > and man, this is a > subject unto itself! > > > -Original Message- > From: Wyatt, T. Rob > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 10, 2003 8:27 AM > To: [EMAIL PROTECTED] > Subject: Re: Penetrating an outbound firewall > > > You can't. Without going into too much detail, you > would need an agent that > doesn't rely on the command server, a command server > that used a different > queue, or you would have to define the queue and > start the command server > each time. These options may seem like a royal pain > but then the whole > purpose is to make it hard to administer the QMgr by > building significant > hurdles for a malicious user to overcome. With > appropriate automation, none > of these are particularly burdensome for the > legitimate admin team. > > -- T.Rob > > -----Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 09, 2003 8:47 PM > To: [EMAIL PROTECTED] > Subject: Re: Penetrating an outbound firewall > > > > T.Rob, > > If you delete the SYSTEM.ADMIN.COMMAND.QUEUE how do > you send command > messages ?... sorry if this appears to be a stupid > question. > > Sid > > -Original Message- > From: Wyatt, T. Rob > [mailto:[EMAIL PROTECTED] > Sent: Saturday, 6 September 2003 6:44 AM > To: [EMAIL PROTECTED] > Subject: Re: Penetrating an outbound firewall > > > Peter, > > 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 > listen
Re: Penetrating an outbound firewall
Try http://www.sjg-enterpriseintegration.com/oamsecurity.asp and http://www.sjg-enterpriseintegration.com/closingmqholes.asp --- "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote: > T.Rob, > What do you think of just stopping the command > server? My thinking is if > they have access to the box to start the command > server locally, they can > just as easily use runmqsc to create the queue. > True, it is an extra step, > but does it buy us anything really to delete the > command queue on top of > stopping the command server? > > > > > As a side note, does anyone know of an MQ class just > for security. I am > writing up a doc for Security for MQ at our company, > and man, this is a > subject unto itself! > > > -Original Message- > From: Wyatt, T. Rob > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 10, 2003 8:27 AM > To: [EMAIL PROTECTED] > Subject: Re: Penetrating an outbound firewall > > > You can't. Without going into too much detail, you > would need an agent that > doesn't rely on the command server, a command server > that used a different > queue, or you would have to define the queue and > start the command server > each time. These options may seem like a royal pain > but then the whole > purpose is to make it hard to administer the QMgr by > building significant > hurdles for a malicious user to overcome. With > appropriate automation, none > of these are particularly burdensome for the > legitimate admin team. > > -- T.Rob > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 09, 2003 8:47 PM > To: [EMAIL PROTECTED] > Subject: Re: Penetrating an outbound firewall > > > > T.Rob, > > If you delete the SYSTEM.ADMIN.COMMAND.QUEUE how do > you send command > messages ?... sorry if this appears to be a stupid > question. > > Sid > > -Original Message- > From: Wyatt, T. Rob > [mailto:[EMAIL PROTECTED] > Sent: Saturday, 6 September 2003 6:44 AM > To: [EMAIL PROTECTED] > Subject: Re: Penetrating an outbound firewall > > > Peter, > > 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 firewal
Re: Penetrating an outbound firewall
I think you should be able to create queues using the LIKE parameter. Sam --- "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote: > T.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 , > 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 firewall > > > Peter, > > 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 firewall > > > T.Rob, in regards to your last paragraph, is that > still necessary if > > A. Your queue manager is a dedicated one just for > outbound messaging (to > other companies) sitting in the DMZ > > and > > B. 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 P
Re: Penetrating an outbound firewall
Title: Message T.Rob, What do you think of just stopping the command server? My thinking is if they have access to the box to start the command server locally, they can just as easily use runmqsc to create the queue. True, it is an extra step, but does it buy us anything really to delete the command queue on top of stopping the command server? As a side note, does anyone know of an MQ class just for security. I am writing up a doc for Security for MQ at our company, and man, this is a subject unto itself! -Original Message-From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED]Sent: Wednesday, September 10, 2003 8:27 AMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall You can't. Without going into too much detail, you would need an agent that doesn't rely on the command server, a command server that used a different queue, or you would have to define the queue and start the command server each time. These options may seem like a royal pain but then the whole purpose is to make it hard to administer the QMgr by building significant hurdles for a malicious user to overcome. With appropriate automation, none of these are particularly burdensome for the legitimate admin team. -- T.Rob -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]Sent: Tuesday, September 09, 2003 8:47 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.Rob, If you delete the SYSTEM.ADMIN.COMMAND.QUEUE how do you send command messages ?... sorry if this appears to be a stupid question. Sid -Original Message-From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Saturday, 6 September 2003 6:44 AMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Peter, 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.Rob, in regards to your last paragraph, is that still necessary if A. Your queue manager is a dedicated one just for outbound messaging (to other companies) sitting in the DMZ and B. 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
Re: Penetrating an outbound firewall
Title: Penetrating an outbound firewall T.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 , 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Peter, 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.Rob, in regards to your last paragraph, is that still necessary if A. Your queue manager is a dedicated one just for outbound messaging (to other companies) sitting in the DMZ and B. 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Doug, We are using direct MQ connections with firewall rules as specified in MA86 (http://www-3.ibm.com/software/integration/support/supportpacs/individual/supportpacs/ma86.pdf). This 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 p
Re: Penetrating an outbound firewall
Title: Message You can't. Without going into too much detail, you would need an agent that doesn't rely on the command server, a command server that used a different queue, or you would have to define the queue and start the command server each time. These options may seem like a royal pain but then the whole purpose is to make it hard to administer the QMgr by building significant hurdles for a malicious user to overcome. With appropriate automation, none of these are particularly burdensome for the legitimate admin team. -- T.Rob -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]Sent: Tuesday, September 09, 2003 8:47 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.Rob, If you delete the SYSTEM.ADMIN.COMMAND.QUEUE how do you send command messages ?... sorry if this appears to be a stupid question. Sid -Original Message-From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Saturday, 6 September 2003 6:44 AMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Peter, 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.Rob, in regards to your last paragraph, is that still necessary if A. Your queue manager is a dedicated one just for outbound messaging (to other companies) sitting in the DMZ and B. 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Doug, We are using direct MQ connections with firewall rules as specified in MA86 (http://www-3.ibm.com/software/integration/support/supportpacs/individual/supportpacs/ma86.pdf). This 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 si
Re: Penetrating an outbound firewall
Title: Message T.Rob, If you delete the SYSTEM.ADMIN.COMMAND.QUEUE how do you send command messages ?... sorry if this appears to be a stupid question. Sid -Original Message-From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Saturday, 6 September 2003 6:44 AMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Peter, 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.Rob, in regards to your last paragraph, is that still necessary if A. Your queue manager is a dedicated one just for outbound messaging (to other companies) sitting in the DMZ and B. 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Doug, We are using direct MQ connections with firewall rules as specified in MA86 (http://www-3.ibm.com/software/integration/support/supportpacs/individual/supportpacs/ma86.pdf). This 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 crea
Re: Penetrating an outbound firewall
Title: Message Doug, Outbound restriction is becoming a real pain in the arse for us, it seams every site we install our client software on thinks they will stop virus's if the block ALL outbound ports on a firewall! You need the network guys to open up the port and host combination so you can connect to your server, you also need to make sure it does NATing correctly and allows the host to return packets. Sid -Original Message-From: Pierson, Doug (ITD) [mailto:[EMAIL PROTECTED] Sent: Saturday, 6 September 2003 12:30 AMTo: [EMAIL PROTECTED]Subject: Penetrating an outbound firewall Hi 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
Re: Penetrating an outbound firewall
Title: Penetrating an outbound firewall Peter, 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall T.Rob, in regards to your last paragraph, is that still necessary if A. Your queue manager is a dedicated one just for outbound messaging (to other companies) sitting in the DMZ and B. 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Doug, We are using direct MQ connections with firewall rules as specified in MA86 (http://www-3.ibm.com/software/integration/support/supportpacs/individual/supportpacs/ma86.pdf). This 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 sp
Re: Penetrating an outbound firewall
Title: Penetrating an outbound firewall T.Rob, in regards to your last paragraph, is that still necessary if A. Your queue manager is a dedicated one just for outbound messaging (to other companies) sitting in the DMZ and B. 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 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Doug, We are using direct MQ connections with firewall rules as specified in MA86 (http://www-3.ibm.com/software/integration/support/supportpacs/individual/supportpacs/ma86.pdf). This 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 AMTo: [EMAIL PROTECTED]Subject: Penetrating an outbound firewall Hi 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.
Re: Penetrating an outbound firewall
Title: Message T.Rob, Excellent information, thankyou. I appreciate your taking the time to respond! Regards, Doug -Original Message-From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2003 12:19 PMTo: [EMAIL PROTECTED]Subject: Re: Penetrating an outbound firewall Doug, We are using direct MQ connections with firewall rules as specified in MA86 (http://www-3.ibm.com/software/integration/support/supportpacs/individual/supportpacs/ma86.pdf). This 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 AMTo: [EMAIL PROTECTED]Subject: Penetrating an outbound firewall Hi 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
Re: Penetrating an outbound firewall
Title: Penetrating an outbound firewall Doug, We are using direct MQ connections with firewall rules as specified in MA86 (http://www-3.ibm.com/software/integration/support/supportpacs/individual/supportpacs/ma86.pdf). This 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 AMTo: [EMAIL PROTECTED]Subject: Penetrating an outbound firewall Hi 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
Penetrating an outbound firewall
Title: Penetrating an outbound firewall Hi 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