| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Avoiding BlockIP2 |
« View previous topic :: View next topic » |
| Author |
Message
|
| emiranda |
 Posted: Mon Jun 28, 2010 1:55 am Post subject: Avoiding BlockIP2 |
 |
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
Chaps, I was wondering a way to avoid the use of BlockIP2 exit in a very specific requirement from the security guys. Here is the picture:
| Code: |
C1QM1 C1QM2 ... C1QMn
|| || ... ||
.--------------------.
| C1C2QMGW |
'--------------------'
|| || ... ||
C2QM1 C2QM2 ... C2QMn
|
A Cluster network with 2 clusters C1 & C2, a Gateway QM overlaps both clusters, where C1 can't reach C2 queues and vice-versa. Applications put msgs in non-clustered QAs (QA1, QA2... QAn) which point to clustered QRs on the Gateway (QR1, QR2... QRn), which point to QLs on the C2 Qmgrs (QL1, QL2... QLn).
All objects are OAMed and connections are SSLed. Messages are to and from C1QM1 - C2QM1, C1QM2 - C2QM2, C1QMn - C2QMn etc.
The allegation is if someone hacks a queue on C1QM1 with sufficient ability/authority to change its destination (let's say QA1 on C1QM1 to point to QR2 on C1C2QMGW, instead of its original QR1 destination) the message could end up in QL2 on C2QM2, which we don't want. BlockIP2 checks DN and allows MCAUSERID override, so it would assign a C1QM1 MCAUSERID to the message, preventing it to be put in a C2QM2 queue, which only allows put to C1QM2 users.
Despite my poor drawing, is that clear enough?
I would like to avoid the use of BlockIP2 exit because of a) it is an "AS-IS" support and b) it will need us to code chadexit as well (z/OS on the cluster)
Apparently, OS login authentication (which grants only valid users to get into the systems), plus SSL (which assures partnership between servers), plus OAM (which controls user authority to the object) are not enough...
I though about SSLPEER to check SSL connections but still it is limited to chls, and once a valid SSL connection goes through, a valid user hacked from a valid but undesired server still could put messages through... I know it's paranoid, but...
Any thoughts?
_________________
Warm Regards,
EM |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Mon Jun 28, 2010 4:43 am Post subject: Re: Avoiding BlockIP2 |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| emiranda wrote: |
a Gateway QM overlaps both clusters,
|
I hope that QM is Highly Available.
| emiranda wrote: |
All objects are OAMed and connections are SSLed.
|
All apps connect only via SVRCONN channels? All apps are MQ Clients?
| emiranda wrote: |
Messages are to and from C1QM1 - C2QM1, C1QM2 - C2QM2, C1QMn - C2QMn etc.
|
If C1QM1 only every intends to send to C2QM1, I don't understand why you have MQ clustering. Plain point to point would accomplish the same thing and be much simpler.
| emiranda wrote: |
| The allegation is if someone hacks a queue on C1QM1 with sufficient ability/authority to change its destination (let's say QA1 on C1QM1 to point to QR2 on C1C2QMGW, instead of its original QR1 destination) the message could end up in QL2 on C2QM2, which we don't want. BlockIP2 checks DN and allows MCAUSERID override, so it would assign a C1QM1 MCAUSERID to the message, preventing it to be put in a C2QM2 queue, which only allows put to C1QM2 users. |
All incoming channels (SVRCONNs, RCVRs, CLUSRCVRs, RQSTRs) need to have an MCAUSER ID hard coded that does not have access to the SYSTEM.ADMIN.COMMAND.QUEUE. Any client channels that need this access (for an MQ Admin for MO71 or MQ Explorer for example) need to be Security Exit or SSLPEER protected. This will prevent users from other systems changing queue definitions. As for local users, well, you have to rely on security measures that prevent bad boys from using root or being in the mqm group. Otherwise you just have to trust root and mqm members.
Or go to z/OS and use RACF, where the RACF admins can have complete control over what anyone can do, even the MQ admins (true separation of duties). But you still have to trust the RACF admins in this case.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| emiranda |
| Posted: Mon Jun 28, 2010 5:39 am Post subject: Re: Avoiding BlockIP2 |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
Thanks Peter.
- Yes, QMgrs are HA
- All Apps run locally on their Qmgr servers
| PeterPotkay wrote: |
| If C1QM1 only every intends to send to C2QM1, I don't understand why you have MQ clustering. Plain point to point would accomplish the same thing and be much simpler. |
The scenario simplifies a more complex interconnection where C1QM1-2-n qmgrs address msgs to a group of C2QM1-2-n Qmgrs. The point is some queues are restricted to specific Qmgrs. Also - the designed environment is doubled for load balancing purposes.
| PeterPotkay wrote: |
| All incoming channels (SVRCONNs, RCVRs, CLUSRCVRs, RQSTRs) need to have an MCAUSER ID hard coded that does not have access to the SYSTEM.ADMIN.COMMAND.QUEUE. |
It has.
| PeterPotkay wrote: |
| As for local users, well, you have to rely on security measures that prevent bad boys from using root or being in the mqm group. Otherwise you just have to trust root and mqm members. Or go to z/OS and use RACF, where the RACF admins can have complete control over what anyone can do, even the MQ admins (true separation of duties). But you still have to trust the RACF admins in this case. |
Here is where I lack arguments to convince security not to use BlockIP2... they don't like the idea of trusting someone, even though in the end there's always a way in, the more are the lockers, the better is the lock, and I still have to use BlockIP2... 
The question remains: Does the exit really provides an extra layer of security we can't cover without it? 
Thanks again.
_________________
Warm Regards,
EM |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 28, 2010 8:18 am Post subject: Re: Avoiding BlockIP2 |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| emiranda wrote: |
| they don't like the idea of trusting someone |
Sooner or later the security people have to trust someone. I've been where you are and that statement is not intended to patronise or belittle your situation. I've met the mind set that says even admins shouldn't be trusted and the best answer I've come up with is non-technical. You can remove all access to root & mqm from "real" people, lock the id's in the security guy's safe and then you're good with what you have.
I've heard of one site where they achieved something close to what you seem to be driving towards. Everything was locked up, no su, no sudo, and root was under the control of security, requiring a form to be given the password and the password changed after each use. It worked fine until there was a serious problem and they discovered the password hadn't been changed to what security thought it had been.
Most sane security people access that there are some gaps in technical security especially around admin access, and fill them with audited sudo & similar procedures.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jun 28, 2010 11:05 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Well, SSL with a careful SSLPEER setting can insure only the intended entity connects, assuming you trust the client side SSL cert doesn't grow legs.
A fully supported exit like Capitalware's MQAUSX can insure that only the intended entity connects, assuming the id/ password wasn't shared.
Or you can make the channels "weak" by tagging them with MCAUSErs that cannot do what you want to prevent. Or just stop the channels.
For remote connections you have to trust the password or SSL cert owner not to share it.
For local connections, you have to limit the population of users to only the people that need that level of access, and if they have MQ admin access (mqm group or root who can modify the mqm group membership), you just have to trust them not to do something wrong.
Yes, you can avoid use BlockIP. But it may mean spending some dollars (buy an exit or SSL certs). Or removing some functionality (weaken or disable the channels).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| emiranda |
| Posted: Tue Jun 29, 2010 12:05 am Post subject: |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
Thanks for your replies guys...
| PeterPotkay wrote: |
| Well, SSL with a careful SSLPEER setting can insure only the intended entity connects, assuming you trust the client side SSL cert doesn't grow legs. |
The problem still is IF someone gets into the box (SSL Peer will be OK) and send messages to the "wrong" Qmgr.
| PeterPotkay wrote: |
| Or you can make the channels "weak" by tagging them with MCAUSErs that cannot do what you want to prevent. Or just stop the channels. |
Yes, this is the approach. But then comes BlockIP2 which can override the MCAUSER based on the incoming DN. This would guarantee that valid users, using valid certificates, don't put messages where they shouldn't.
| PeterPotkay wrote: |
| For local connections, you have to limit the population of users to only the people that need that level of access, and if they have MQ admin access (mqm group or root who can modify the mqm group membership), you just have to trust them not to do something wrong. |
| Vitor wrote: |
| Sooner or later the security people have to trust someone. |
He, he, he... there's no word like trust in the Corporate World, I'm affraid! 
| PeterPotkay wrote: |
| Yes, you can avoid use BlockIP. But it may mean spending some dollars (buy an exit or SSL certs). Or removing some functionality (weaken or disable the channels). |
I'd love to, but still don't see the arguments to fight with... 
_________________
Warm Regards,
EM |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 29, 2010 2:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If BlockIP is being proposed to ensure that all connections from some source IP are always put into a specific MCAUSER, then the only way to achieve this with the base product is to have multiple gateway qmgrs. Each customer is then constrained by the network firewall from establishing any connectivity to the wrong listener port.
You should be strongly controlling the customer's network access through the firewall already, to ensure they can only talk to the gateway machine and only talk to the mq listener port on that machine, and can't do anything else. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jun 29, 2010 3:24 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| emiranda wrote: |
Thanks for your replies guys...
| PeterPotkay wrote: |
| Well, SSL with a careful SSLPEER setting can insure only the intended entity connects, assuming you trust the client side SSL cert doesn't grow legs. |
The problem still is IF someone gets into the box (SSL Peer will be OK) and send messages to the "wrong" Qmgr.
|
With properly set up SSL on a channel with a very restrictive SSLPEER, or a password using Security Exit, one and only one entity can connect over that channel. Based on the MCAUSER ID on that channel, you have complete control over what that connection can do. Set up right and there is no way the wrong entity can access the allowed queue(s) via that channel, and no way the right entity can access to other queues.
SSL or Exits have no capability when it comes to preventing users logging onto the box directly or for apps running locally and connecting in bindings mode.
| emiranda wrote: |
| PeterPotkay wrote: |
| Yes, you can avoid use BlockIP. But it may mean spending some dollars (buy an exit or SSL certs). Or removing some functionality (weaken or disable the channels). |
I'd love to, but still don't see the arguments to fight with... |
BlockIP (or SSL or a supported exit) have nothing to do with who can log onto the box or what apps connected in bindings mode can do, so the for / against arguement as it relates to BlockIP is only relevent for channel connections.
For channel connections, if you want to avoid Block IP, you either weaken or disable the channels to the point where it doesn't matter who connects over them (doesn't sound feasible in your scenario), or, you use a supported exit like Capitalware MQAUSX if your company has reservations about using freeware in production, or you use SSL instead of an exit solution.
I think that pretty much sums it up. If they don't mind free AS-IS software protecting the connections, then there really is no strong argument against using Block IP. It can do the job from what I know about it - I have never used it myself. We use MQAUSX on this account.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 29, 2010 7:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| emiranda wrote: |
| The problem still is IF someone gets into the box (SSL Peer will be OK) and send messages to the "wrong" Qmgr. |
If "someone" gets onto the box, you have bigger problems than WMQ security and nothing WMQ can do to help you. This is part of the point I was making.
| emiranda wrote: |
| Vitor wrote: |
| Sooner or later the security people have to trust someone. |
He, he, he... there's no word like trust in the Corporate World, I'm affraid! |
Where exactly do you think I work? Mars? A charity? 
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Thu Jul 01, 2010 11:19 am; edited 1 time in total |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jun 29, 2010 2:03 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| emiranda wrote: |
| there's no word like trust in the Corporate World, I'm affraid! |
Oh... yes there is .... only it has a complete different meaning and is tied to wealth and money... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| emiranda |
| Posted: Thu Jul 01, 2010 2:38 am Post subject: |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
| PeterPotkay wrote: |
With properly set up SSL on a channel with a very restrictive SSLPEER, or a password using Security Exit, one and only one entity can connect over that channel. Based on the MCAUSER ID on that channel, you have complete control over what that connection can do. Set up right and there is no way the wrong entity can access the allowed queue(s) via that channel, and no way the right entity can access to other queues.
SSL or Exits have no capability when it comes to preventing users logging onto the box directly or for apps running locally and connecting in bindings mode. |
That's perfect alright, as the user is allowed to go through the channel (Cluster1), but still could put a msg into a queue on Cluster2 (valid user, auth/knowledge to hack QA/QR to point to whatever queue in Cluster2). It's a gateway overlaping cluster...
| PeterPotkay wrote: |
| BlockIP (or SSL or a supported exit) have nothing to do with who can log onto the box or what apps connected in bindings mode can do, so the for / against arguement as it relates to BlockIP is only relevent for channel connections. |
And this is all about channels...
| PeterPotkay wrote: |
| If they don't mind free AS-IS software protecting the connections, then there really is no strong argument against using Block IP. |
| mqjeff wrote: |
| If BlockIP is being proposed to ensure that all connections from some source IP are always put into a specific MCAUSER, then the only way to achieve this with the base product is to have multiple gateway qmgrs. Each customer is then constrained by the network firewall from establishing any connectivity to the wrong listener port. |
I'm affraid this is the only solution...
_________________
Warm Regards,
EM |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jul 01, 2010 2:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| emiranda wrote: |
| mqjeff wrote: |
| If BlockIP is being proposed to ensure that all connections from some source IP are always put into a specific MCAUSER, then the only way to achieve this with the base product is to have multiple gateway qmgrs. Each customer is then constrained by the network firewall from establishing any connectivity to the wrong listener port. |
I'm affraid this is the only solution... |
Now, MQIPT might have some additional capabilities here. But MQIPT is not "base product". It's not an unsupported exit, either. It's a cat 3 sPac, which means it's covered by IBM support. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jul 01, 2010 10:43 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| emiranda wrote: |
| PeterPotkay wrote: |
With properly set up SSL on a channel with a very restrictive SSLPEER, or a password using Security Exit, one and only one entity can connect over that channel. Based on the MCAUSER ID on that channel, you have complete control over what that connection can do. Set up right and there is no way the wrong entity can access the allowed queue(s) via that channel, and no way the right entity can access to other queues.
SSL or Exits have no capability when it comes to preventing users logging onto the box directly or for apps running locally and connecting in bindings mode. |
That's perfect alright, as the user is allowed to go through the channel (Cluster1), but still could put a msg into a queue on Cluster2 (valid user, auth/knowledge to hack QA/QR to point to whatever queue in Cluster2). It's a gateway overlaping cluster...
|
How is this user "going thru a channel" going to alter a queue unless you granted them the ability to do that, either by leaving the MCAUSER field blank or by tagging the channel with an ID that you allowed to do that?
Tag the channels with an MCAUSER that cannot alter objects.
But if you need to prevent the users (coming over channels) from putting to queues that are not theirs, you will need an Exit of some sort or SSL. Or that multiple QM / firewall solution jeff mentioned.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
