MQSeries.net :: View topic - Hub and spoke security

MQSeries.net

Tech Exchange

Education

Certifications

Library

Info Center

SupportPacs

FAQÂ Â

Usergroups

RSS Feed - WebSphere MQ Support

RSS Feed - Message Broker Support

MQSeries.net Forum Index » General Discussion » Hub and spoke security

Goto page 1, 2 Next

Hub and spoke security

« View previous topic :: View next topic »

Author

Message

billybong

Posted: Fri Nov 10, 2006 6:16 am Post subject: Hub and spoke security

Disciple

Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden

Hi all!

We're implementing a hub and spoke solution on our MQ environment and one question is still nagging in my head. What is the best practice to shield the spoke queue managers from each other? Take this env as an example.

H = Hub qmgr
A = Spoke qmgr
B = Spoke qmgr
C = Spoke qmgr

A.1 = Queue on qmgr A, B.1 = queue on qmgr B etc......

If both A and B are to connect to C they should often not be able to connect to the same queues. Say that an application on A puts to C.1 while another on B puts to C.2 .

How do you best shield C.2 from queue manager A and C.1 from manager B?

If you used a P2P env it's easy by specifying different MCAUSERS on channel A.C than B.C, but in the hub environment all messages go trough H.C and therefore will use the same uid. Are message exits the only alternative here or am I missing something?

-------- edited typo
_________________
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0
IBM Certified System Administrator - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere DataPower

Vitor

Posted: Fri Nov 10, 2006 6:24 am Post subject:

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

Is it impractical / politically impossible to authenticate at an individual user level, i.e. must you set MCAUSER? If this is not set you add users to groups then give authorities to groups on a queue by queue basis.
_________________
Honesty is the best policy.
Insanity is the best defence.

billybong

Posted: Fri Nov 10, 2006 6:30 am Post subject:

Disciple

Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden

I've been thinking about that solution too, but from what I can see it opens up too many security holes. If someone would get mqm access to a spoke and the MCAUSER wasn't set on any recievers the whole mq network could be at risk.

Knock knock mr SYSTEM.ADMIN.COMMAND.QUEUE

Vitor wrote:

_________________
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0
IBM Certified System Administrator - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere DataPower

jefflowrey

Posted: Fri Nov 10, 2006 6:31 am Post subject:

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

Read the first part of this carefully.
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzae.doc/sec9.htm

Read about PUTAUT.

Consider very strongly using QALIASes or QREMOTEs on the sender end.
_________________
I am *not* the model of the modern major general.

hopsala

Posted: Fri Nov 10, 2006 6:48 am Post subject:

Guardian

Joined: 24 Sep 2004
Posts: 960

To add to the discussion - though PUTAUT security seems like the natural solution here, it has two very serious drawbacks: First, that it requires that the sender site be trusted, otherwise he will simply forge the Context.UserId field; Second, that you have to distribute all users and relevant authorizations to all QMs on the network, which is usually quite hassle to maintain. For these two reasons I usually search for other solutions.

The biggest question here is - do you have complete control over all QMs?

If the answer is yes, no problem - use remote queue authorities as jeff had suggested. If the answer is no, there are several solutions, ranging from encrypting the message body to using a channel per spoke-spoke connection (so that in the hub QM you'll have three sender channels - QMH.TO.QMC.FROM.QMA - ugly but it works)

Will supply a more detailed description upon request...

billybong

Posted: Fri Nov 10, 2006 6:48 am Post subject:

Disciple

Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden

Thanks Jeoff, as always you're quick...

But I fail to see how altering the PUTAUT would help my situation.
If I set it to CTX I could open up the queues for a user on another spoke which is exactly what I want. But how will I be sure that user is not mqm? Someone could (I'm being paranoid here) possibly get mqm access to a spoke qmgr, create a remote queue pointing at any queue manager in the network and have a blast with all our command queues.

Is this something you "have to live with" or do you have an example of how this could be avoided.

jefflowrey wrote:

billybong

Posted: Fri Nov 10, 2006 6:53 am Post subject:

Disciple

Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden

Yes, I do have control over all the queue managers, so PUTAUT is not a bad option.

The problems comes when we want to introduce partners trough the use of MQIPT in the picture. I'm not an expert on the MQIPT package so if someone knows about a feature that solves this issue I'm all ears. But if the MQIPT works exactly as queue managers one of our partners could potentially be running their MQ applications as mqm which puts our environment at risk.

The partners connects to a client hub btw, not directly to the main hub.
_________________
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0
IBM Certified System Administrator - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere DataPower

hopsala

Posted: Fri Nov 10, 2006 7:05 am Post subject:

Guardian

Joined: 24 Sep 2004
Posts: 960

I also know little about MQIPT, but I don't believe it changes anything concerning the topic at hand.

If you have complete control over all QMs, I wouldn't bother using context security (especially since in your case the partner application determines the userid, which you have no control over). Simply use remote queues. For example on QMA you'd have remote queues QMC1 QMC2, and on QMB a similar set, to each application (that is, SVRCONN MCAUSER allocated to that application) give only the appropriate queue auths - and voila! Block the transmission to the wrong queue at the origin - at the sender spoke - instead of at the hub.

And if you're worried someone might send without using remote queue, simply change the transmission queue name from the usual "QMB" to something like "TO.QMB", and no one will be able to send through it rather than by remote queue.

jefflowrey

Posted: Fri Nov 10, 2006 7:23 am Post subject:

Grand Poobah

Joined: 16 Oct 2002
Posts: 19981

For messages coming in from external parties, SSL + MCAUser is your best friend - and MCAUser is a very good start on it's own.

This is ensures that messages that get delivered to *your* queue manager are authorized to an ID under *your* control.

Otherwise, hopsala gave you a good explanation of why I said "Strongly consider using QREMOTEs and QALIASes on the sender side".

In the case of messages coming from external parties, in this case the "sender side" is your client hub. Force them to be particular users using MCAUser on channels, and then only give them QREMOTE or QALIAS names and only authorize their users to those particular objects.

And lock down your transmit queues.
_________________
I am *not* the model of the modern major general.

billybong

Posted: Fri Nov 10, 2006 7:28 am Post subject:

Disciple

Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden

Thanks a lot! I get it now.

- All remote q's means MQ admins have full control over the routing. (we already use this)

- MCAUSER = some hub user on the spokes, means we dont have to deal with "mqm" attacks. (already used)

- XMITQ != queuemanagernames, we're not concerned with developers sending to the wrong manager/queue by mistake since they only use RQ's. (not used now, really solved the issue)

I'll do some experimenting and "hacking" on my own to see if I can break it, but it should be safe enough.

hopsala wrote:

RogerLacroix

Posted: Sun Nov 12, 2006 12:45 pm Post subject:

Jedi Knight

Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada

Hi,

Remember, your weakest link (spoke) will give a developer / hacker (whatever) full access to any and all queue managers.

billybong wrote:

I'll do some experimenting and "hacking" on my own to see if I can break it, but it should be safe enough.

I really hope that it is an off-hand comment rather than you simply don't want to do the work to make it right.

You do not have a secure MQ environment if any of the following are true:

(1) On the hub or spoke QMgrs, if you have ANY client connection channels that are open (i.e. no SSL and no security exit) including SYSTEM channels with a blank MCAUSER field.

(2) On the any QMgr, if you have some client channels using SSL or security exit and some without.

(3) On the any QMgr, if you exclusively use SSL or security exit but you use mix UserIds on the MCAUSER field.

Explanation:

(1) Anyone, anytime can do whatever they want to whatever QMgr they want.

(2) Sure you may have security on some channels but a developer or hacker would just use the unsecured channel.

(3) The hacker would use a PC that is configured with SSL and then find a channel that has 'mqm' (or equivalent UserId) in the channel's MCAUSER field.

Now # 3 is almost correct, but if any UserId in any MCAUSER field has access to command queue or ability to use an alternate UserId then it is all for not.

I do MQ security reviews for different customers all the time. It is extremely rare (i.e. 1 in 20 or more likely 1 in 50) that I cannot hack into a queue manager on any system including Unix and mainframe QMgrs. I let the MQ Admin tell me how secure their Unix or mainframe QMgrs are then I simply attract an orphan (out laying) queue manager on Unix or Windows and then I gain access their secure Unix or mainframe QMgr.

I then write a report on how the CIO of the company can go to jail because of Sarbanes-Oxley or HIPAA rules and then let the finger pointing begin.

The bottom-line is that half-ass security is really no security at all. Remember, all it ever takes is 1 unsecured client channel on any QMgr to comprise the 'important' QMgr.

There are 3 solutions in the market-place that will properly protect your MQ Environment:
- Capitalware's MQ Authenticate User Security Exit
- IBM's WebSphere MQ Extended Security Edition
- IBM's Tivoli Access Manager for Business Integration (TAMBI)

Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter

billybong

Posted: Sun Nov 12, 2006 11:51 pm Post subject:

Disciple

Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden

RogerLacroix wrote:

I really hope that it is an off-hand comment rather than you simply don't want to do the work to make it right.

I would not have started this thread if I was'nt interested in doing the work. After all, its me those fingers will point at in the end, so please save me those remarks.

I still fail to see how someone could do any harm to the other queue managers if they're able to connect as i.e. mqm by using an unsecure client channel on a spoke. If all reciever channels on the hub are locked by specifying MCAUSER the mqm user on the spoke will not have access to the command queues at the other spokes.

Remember, I'm being hypotethical here since we have already taken care of security in our p2p environment by doing the exact things you've mentioned. The thread was started since I was concerned with how to lock up individual queues from specific spoke qmgrs.
_________________
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0
IBM Certified System Administrator - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere DataPower

Michael Dag

Posted: Mon Nov 13, 2006 1:47 pm Post subject:

Jedi Knight

Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)

RogerLacroix wrote:

I then write a report on how the CIO of the company can go to jail because of Sarbanes-Oxley or HIPAA rules and then let the finger pointing begin.

You do this before or after you get paid ?

_________________
Michael

MQSystems Facebook page

RogerLacroix

Posted: Mon Nov 13, 2006 9:54 pm Post subject:

Jedi Knight

Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada

Michael Dag wrote:

RogerLacroix wrote:

I then write a report on how the CIO of the company can go to jail because of Sarbanes-Oxley or HIPAA rules and then let the finger pointing begin.

You do this before or after you get paid ?

I always made sure the SOW (Statement of Work) is signed first.

Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter

RogerLacroix

Posted: Mon Nov 13, 2006 10:05 pm Post subject:

Jedi Knight

Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada

billybong wrote:

I still fail to see how someone could do any harm to the other queue managers if they're able to connect as i.e. mqm by using an unsecure client channel on a spoke. If all reciever channels on the hub are locked by specifying MCAUSER the mqm user on the spoke will not have access to the command queues at the other spokes.

Hi,

You are thinking one-dimensional. You need to remember the point of MQ is to move messages between queue managers.

How do you move messages between QMgrs?
- You can use the default XMITQ
- You can use a QMgr Alias
- You can use a remote queue
- You can use an XMITQ when the name matches the remote QMgr name
- You can use an XMITQ when the name does not match the remote QMgr name (i.e. write directly to the XMITQ including creating the XMITQ header)

So, I simply find the easiest path on the spoke QMgr to send a message to the hub QMgr's command queue and retrieve a list of queues and channels on the hub QMgr.

(1) If there is a useable client channel then use it to do whatever I want.

(2) If there is not a client channel on the hub that I can use then I simple create a client channel on the hub QMgr. Next do whatever I want to do then delete the client channel when I am done.

So, it would take me 2 or 3 minutes to hack into your hub QMgr.

Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter

Display posts from previous:

Goto page 1, 2 Next

Page 1 of 2

MQSeries.net Forum Index » General Discussion » Hub and spoke security

Jump to:

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

Protected by Anti-Spam ACP