Author |
Message
|
jgooch |
Posted: Thu Sep 18, 2003 7:50 am Post subject: Authentication. |
|
|
 Acolyte
Joined: 29 May 2002 Posts: 63 Location: UK
|
Peeps,
We had an issue this morning where a developer accidentally set up a qmgr on his PC to be a member of our production cluster. Bascially, he used a production mqsc script and created the CLUSSDR and CLUSRCVR channels. Unfortunately, it was on the same port as an existing WMQI qmgr and the cluster got in a bit of a muddle. Messages were failing with 2085 (object not found).
The resolution was fairly simple (we'd automatically captured the error messages and so just had to remove the developer's qmgr from the cluster and re-submit the messages) - I think it would have been more complicated had someone run a RESET or REFRESH CLUSTER before we spotted it.
My question is, what is the simplest way to add some level of authentication to a cluster so that only certain qmgrs are allowed to enter it? Is this possible?
Thanks,
J. |
|
Back to top |
|
 |
interactivechannel |
Posted: Fri Sep 19, 2003 1:35 am Post subject: |
|
|
Voyager
Joined: 20 May 2003 Posts: 94 Location: uk
|
|
Back to top |
|
 |
jgooch |
Posted: Fri Sep 19, 2003 1:42 am Post subject: |
|
|
 Acolyte
Joined: 29 May 2002 Posts: 63 Location: UK
|
Thanks for the (albeit brief ) reply.
Having spent a 'happy' few minutes with the manual, I found this:-
Quote: |
Preventing queue managers joining a cluster
If you want to ensure that only certain authorized queue managers attempt to join a cluster, you must either use a security exit program on the cluster-receiver channel, or write an exit program to prevent unauthorized queue managers from writing to SYSTEM.CLUSTER.COMMAND.QUEUE. Do not restrict access to SYSTEM.CLUSTER.COMMAND.QUEUE such that no queue manager can write to it, or you would prevent any queue manager from joining the cluster. |
Pardon my ignorance but when they say "cluster receiver channel" are they referring to the repositories' channels?
I can feel that the phrase "can-of-worms" is going to raise its head with this one...
J. |
|
Back to top |
|
 |
interactivechannel |
Posted: Fri Sep 19, 2003 3:07 am Post subject: |
|
|
Voyager
Joined: 20 May 2003 Posts: 94 Location: uk
|
You don't need to go quite that far.
Upgrade to 5.3, if not already there, and decide on your PKI policy. I.e Are you going to use self-signed certificate exchange (easiest) or a CA with a CRL?
Generate certificates and add to queue managers. MQ security manual and redbook should help with this bit. Add cipherspec to CLUSRCVR and CLUSSDR to repository queue manager channels one at a time. Now no-one can connect to your cluster unless, their public certificate is in the key repository of the repository queue manager, or they have a certificate issued by a CA in the key repository. |
|
Back to top |
|
 |
EddieA |
Posted: Fri Sep 19, 2003 6:42 am Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
J, to answer your question. Yes, I too would guess that they are talking about the channels on the FULL repositories. That's where any other queue manager joinging the cluster has to connect to.
To which he asks a question out loud, to no one in particular. I wonder what happens when a queue manager tries to join a cluster, but points the Cluster Sender to a partial repository instead of the full. Hmmmm, I feel an experiment coming on.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
jgooch |
Posted: Fri Sep 19, 2003 6:50 am Post subject: |
|
|
 Acolyte
Joined: 29 May 2002 Posts: 63 Location: UK
|
OK, guys, thanks for the answers so far.
I've been reading up on SSL within MQ, and it seems like it might be a good candidate for this one.
...but...
We're not running v5.3 (CSD04) of MQ throughout our network. Some older servers are running Solaris 5.6 and therefore we're running MQv5.2 CSD07 on these.
1. Does this preclude SSL as a solution? I'm inferring from Interactive's reply that MQ SSL is purely a 5.3 initiative.
2. If we have to go with an exit program solution, can anyone provide a link to an example? Does it have to be written in C? (said the Perl hacker )
Have a good weekend, all.
J. |
|
Back to top |
|
 |
interactivechannel |
Posted: Fri Sep 19, 2003 6:58 am Post subject: |
|
|
Voyager
Joined: 20 May 2003 Posts: 94 Location: uk
|
Upgrade the old servers, as 5.2 isn't supported for much longer. It will probably be quicker than messing around with C. |
|
Back to top |
|
 |
jgooch |
Posted: Fri Sep 19, 2003 7:07 am Post subject: |
|
|
 Acolyte
Joined: 29 May 2002 Posts: 63 Location: UK
|
Fair comment, but MQv5.3 is not supported on Solaris 5.6. This is why we've not upgraded these beyond the CSD07.
So you are saying that I'm in Exit Program Landâ„¢?  |
|
Back to top |
|
 |
oz1ccg |
Posted: Sun Sep 21, 2003 4:16 am Post subject: |
|
|
 Yatiri
Joined: 10 Feb 2002 Posts: 628 Location: Denmark
|
Well this is a new topic (newer raised before ), I did some writing over the summer on this topic.
I find it very easy to protect the cluster from intruders even without using SSL and the administration that gives, The simple answer is a security exit and knowing which connection names(IP-addr) you'll allow, his can also solve the lack of security on the MQ-explore thing.
My small writing is here:http://home19.inet.tele.dk/m-invent/Cluster_security1.htm There are even a link to my security exit.
I hope it can give some inspiration.... You're not the first or last that have faced the Cluster ghost, maybee we should write a WMQ-clustering for dummies book, (all the material is present here on the net, I just have to set it up).
I hope I can help.
Just my $0.02  _________________ Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
Back to top |
|
 |
jgooch |
Posted: Mon Sep 22, 2003 12:18 am Post subject: |
|
|
 Acolyte
Joined: 29 May 2002 Posts: 63 Location: UK
|
oz1ccg wrote: |
...snip...
we should write a WMQ-clustering for dummies book
...snip... |
What are you saying about me?
More seriously, thanks for the reply and the link. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Sep 22, 2003 4:14 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
One other possability is to restrict access to the SYSTEM.CLUSTER.COMMAND.QUEUE using OAM and the PUTAUT attribute on the CLUSRCVR channel. If a rogue QM cannot put to the command queue, it cannot get into the cluster. I have not tried this concept, only have heard about it.
By default, the PUTAUT atribute is set to DEF, which means the USERID that is checked when messages come across this channel is the USERID of the process that started the MCA. The process that starts an MCA is usually the channel initiator or the listener, which means the ID being used is mqm. Basically, if there is no EXIT in place, all the messages (including requests to enter the cluster) come across as mqm.
If you set the PUTAUT attribute to CTX, the info in the UserIdentifier field of the MQMD of each message is used instead. Now this means that THIS ID needs access to open any queue in the cluster. Using OAM you can decide who can put to what queues. Odds are the rogue QM will not be sending messages using an ID that you gave access for. So it wont be able to join the cluster.
This is not an easy solution from an admin standpoint. You gotta make sure all valid IDs are given proper authority using OAM on all QMs in the cluster. In a cluster with lots of QMs, this can be a full time job. But, no exit! Oh yeah, the ID that started the MCA will need authority to set Alternate User Authority on the destination queue. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
oz1ccg |
Posted: Sun Sep 28, 2003 2:24 pm Post subject: |
|
|
 Yatiri
Joined: 10 Feb 2002 Posts: 628 Location: Denmark
|
Yes I did write that... lol
Quote: |
oz1ccg wrote:
...snip...
we should write a WMQ-clustering for dummies book
...snip...
|
I saw i the bookstore a lot of books (small) xyz for dummies, it's not ment to offend anybody, but it seems to me that the manuals are not easy to read and understand, therefore my offtopic idea... ofcause I should have pointed out it was not ment to offend anybody, just as some kind of joke
Anyhow I'm still thinking of writing such a book, but hopefully there will be no buyers arround, because the topic is too easy to understand..
Sorry for that.
Anyway back to business, Peter which USERID is used when the rogue QM joins the cluster ? Ain't that the mqm of the remote site ?? If so how can you make it safe ??
And if you're dealing with a mrs. Blackhat she will ofcause use a valid userid t.x. mqm, or an know mqm-admin userid or root.
If you're reading articles on security the worst one is the insider, and it is difficult to protect against. You can't rely on secrets, because it will be revealt by somebody sometime...
Just my $0.02  _________________ Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Sep 30, 2003 12:29 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Hi Jørgen,
That is true. It is not impossible for the user on the other side to log in as mqm, or root, or as one of your ids, and send commands across that are tagged with this ID.
Security exits are vulnerable to this as well, (they have no way of knowing who is really sitting at the keyboard on the other side),but they have other validation criteria that can at least prove what the ip address is on the requesting side. This would knock out the people who are trying to attack you from an ip address that you have allowed.
However, I have heard it is possible to spoof ip addresses, and that combined with someone logging on as another user is tough to protect against. Adding SSL to the mix should help some more here as the key certificates will be used for authentication.
I suppose it is next to inmpossible to protect yourself 100%. I would like to read your writing at the link provided, but my company's firewall says its a restricted site!!!
I emailed the link to my home and will check it out there. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
oz1ccg |
Posted: Sun Oct 05, 2003 11:43 am Post subject: |
|
|
 Yatiri
Joined: 10 Feb 2002 Posts: 628 Location: Denmark
|
As I mentioned, and as you agree on It's not a simple task to secure a cluster...
What I've done for some clients was to create security exits that was exchanging encrypted credentials. This exits was doing a lot of security stuff, e.g. verifying the userid/password and checked that the given user had the right "extented" credentials. The exchange used a propriority protocol for the exchange...
This solution was covering Z/OS and W2K, and could be extented to other platforms. The actual code may not be published dur to copyrights, so.....
And when introducing different platforms, it also requires other exits to make the security exit working on the clustered channels... as documented in the manuals.
So using overlapping clusters and using exits makes it very difficult for intruders in my clients networks. So when Mrs. Blackhat gets into one server, there are not full access to the rest of the MQ-network, even when having mqm on one QMGR....
Just my $0.02  _________________ Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
Back to top |
|
 |
|