| Author |
Message
|
| mqdogsbody |
 Posted: Fri Jun 04, 2010 4:37 am Post subject: Unspoofable messages. |
 |
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
We have two 3rd-party apps that communicate via an MQ queue, connecting over svrconn channels. We need to prevent anyone or anything other than the correct sender app putting messages on the queue. (We can assume the machine on which the sender app runs is secure ... "not our problem"!)
FWIW I have RTFM, well tried to: the information is scattered everywhere and you rarely get the whole story on one page. I have also managed to write a working security exit (based on red book SG245306).
I see two approaches:
1. Security exits
The trouble with security exits is that they secure individual channels and there seems to be no link between a queue and the channel used to access it. Having a secure channel doesn't really stop baddies accessing the queue via another channel. We cannot lock down all channels at this stage - the risk of disruption is too great!
Our best idea is to set the MCAUSER id on our secure channel to an otherwise unused value and allow only that use to put to the queue.
2. Send/Receive Exits
The idea is to checksum the message on putting and validate the checksum on getting. Using exits makes this invisible to the apps (which we cannot change).
The advantage is seen to be that as long as the message getter is secure and the exit working (which we can assume) it doesn't matter who can put messages to the queue - they cannot generate the correct checksum (as it will be encrypted, time-stamped, have a nonce, ...).
The trouble here is that there seems to be no useful documentation, not least of the TSH structure and what follows in the segment. IBM seem to say "you can use send/rcv exist to do ..." and then don't tell you enough to do anything!!
(For instance I can apparently request space in the transmission buffer, ExitSpace but the section "How you reserve space and use it" tells me nothing about how to use it ... or even where it is.)
Any info would be appreciated.
- where can I put my checksum
- how do I know I have the whole message - it seems to come in chunks
- how do I signal bad message to the app and what will it see
... and more I am sure.
Any ideas. comments, suggestions. help!
-- mqDB -- |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Jun 04, 2010 4:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I'm confused, really.
Why do you need to bother with an exit at all?
If you can assume the sender machine is secure, then you can assume that you can install a certificate on the sender machine and it won't be read by anyone that isn't supposed to read it.
You can create this certificate with an application specific Distinguished Name, which you can then put into the SSLPEER value of the SVRCONN. Once you enable SSLCAUTH(REQUIRED) and configure the qmgr's keyring to trust the sender certificate, then only an application that presents a valid certificate with that exact DN will be allowed to connect to that particular channel.
No Exit Required.
And at least as secure as any other method, especially one you code up yourself without having several years of experience writing and testing exits.
But if you can't at least set an MCAUSER on *all* other channels without interfering with " We cannot lock down all channels at this stage - the risk of disruption is too great! ", then *nothing* you can do will *ensure* that only the right user can put to that specific queue. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 04, 2010 6:05 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| mqjeff wrote: |
But if you can't at least set an MCAUSER on *all* other channels without interfering with " We cannot lock down all channels at this stage - the risk of disruption is too great! ", then *nothing* you can do will *ensure* that only the right user can put to that specific queue. |
Put another way, if EVERY incoming channel (SVRCONNs, RCVRs, CLUSRCVRs, Requestors) isn't prevented from putting to QUEUE.XYZ, it doesn't matter how secure you make client channel CHANNEL.XYZ in hopes that only it will be able to put to QUEUE.XYZ.
Preventing those other channels from putting to QUEUE.XYZ does not mean you have to authenticate all those other channels with Exits and/or SSL. It means they all need to have an MCAUSER value coded that does not have access to QUEUE.XYZ.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Fri Jun 04, 2010 6:22 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| mqjeff wrote: |
| Why do you need to bother with an exit at all? |
Well indeed. Maybe I am barking up the wrong tree!
| mqjeff wrote: |
| you can install a certificate on the sender machine and ... |
I know little about SSL ... maybe I should read more! The view here is that it needs some key management infrastructure we don't have. But maybe a secure machine is enough "infrastructure".
| mqjeff wrote: |
| only an application that presents a valid certificate with that exact DN will be allowed to connect to that particular channel. |
Yes, but as you yourself say, that's not really enough.
I take your point about amateurs dabbling in security, but it seems to me that SSL and a securty exit get us to the same point.
(To an extent though it depends on the level of threat you are hoping to protest against and ours is pretty low, "a user smart enough to use amqsput0 (or a Java equivalent [which is of course far worse])".)
| mqjeff wrote: |
| ... *nothing* you can do will *ensure* that only the right user can put to that specific queue. |
That's the beautiful of the send/rcv exit approach ... baddies can put what they like: their messages will be binned ... as long as the getter goes via the correct channel (which we assume).
| mqjeff wrote: |
| ... if you can't at least set an MCAUSER on *all* other channels without interfering with ... |
AIUI, a blank MCAUSER means "anybody can be anybody" whereas a set one means "anybody can be somebody" ("somebody" meaning "one of the set of MCAUSERs defined"), an improvement, but not much of one.
-- mqDB -- |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jun 04, 2010 6:36 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
| Combination of OAM security (setmqaut) and the free comprehensive channel exit BlockIP2 (why write your own?) works for me. |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Fri Jun 04, 2010 6:45 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| PeterPotkay wrote: |
| it doesn't matter how secure you make client channel CHANNEL.XYZ in hopes that only it will be able to put to QUEUE.XYZ. |
Indeed. As I say
| mqdogsbody wrote: |
| The trouble with security exits is that they secure individual channels and there seems to be no link between a queue and the channel used to access it. Having a secure channel doesn't really stop baddies accessing the queue via another channel. |
| PeterPotkay wrote: |
| It means they all need to have an MCAUSER value coded that does not have access to QUEUE.XYZ. |
I know! Obviously we must do this, but it is deemed "a step too far" at the moment. (I hope it will be done soon.)
But doesn't setting an MCAUSER (and no security exit) mean that "anybody can be somebody"? -- if I connect via a channel with user X then, whoever I am, I have the authority of X.
-- mqDB -- |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Fri Jun 04, 2010 6:47 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| zpat wrote: |
| Combination of OAM security (setmqaut) and the free comprehensive channel exit BlockIP2 (why write your own?) works for me. |
Doesn't BlockIP trust the user ID sent across by the client? (Correct me if I am wrong. but isn't BlockIP server-side only.)
-- mqDB -- |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 04, 2010 7:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqdogsbody wrote: |
| mqjeff wrote: |
| only an application that presents a valid certificate with that exact DN will be allowed to connect to that particular channel. |
Yes, but as you yourself say, that's not really enough.
I take your point about amateurs dabbling in security, but it seems to me that SSL and a securty exit get us to the same point. |
Yes, they get you to the same point. But the built-in support for SSL is a) built-in, b) supported by someone other than you, c) built-in, d) significantly easier to set up than coding an exit, e) significantly more reliable than an untested exit.
I believe that BlockIP will allow you to say "only this particular IP address is allowed to connect to this particular channel, all other IPs are Blocked", without any consideration of user names. It's certainly a better approach than coding your own exit. But it's still extra setup.
To be clear on MCAUSER, an MCAUSER says that "anybody is forced into being somebody". As long as you have any channel, of any kind, coming into this queue manager that does not have any MCAUSER set, then the possibility exists that your queue is not secure.
It may be beyond the scope of the average "I've passed the MQ Developer certification" developer to break into this queue, but you can't assume that from a security perspective. |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Fri Jun 04, 2010 7:43 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| mqjeff wrote: |
| But the built-in support for SSL is ... |
Guess I need to found out more about this and how much work it takes to get it going.
I know so little! How do I obtain a certificate for instance? Where is it stored? How do I tell the server side where it is? How does the server side check it?
| mqjeff wrote: |
| I believe that BlockIP will allow you to say "only this particular IP address is allowed to connect to this particular channel" |
TTBOMK that's correct. That might be enough for us ... setting aside the issue of blank MCAUSERs: let's assume we have sorted that out.
We can trust the IP address. Having a special user ID which is the only one that can access the queue and having that only on our BlockIP2-secure channel means that only users on the correct machine can access the channel. Hence only they can use the special user ID ... and we are safe! Is this correct?
| mqjeff wrote: |
| As long as you have any channel, of any kind, coming into this queue manager that does not have any MCAUSER set, then the possibility exists that your queue is not secure. |
But (sans exit) can't anybody connect via any channel, thus gaining use of the special user ID used for the sensitive queue?
_________________
-- mqDB -- |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 04, 2010 7:59 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9398
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| We have two 3rd-party apps that communicate via an MQ queue, connecting over svrconn channels. We need to prevent anyone or anything other than the correct sender app putting messages on the queue. |
Yes, you are correct that MQ security documentation is scattered.
You might want to look at this problem in another way, namely:
The producer of the message and the consumer of the message need to have a unique (monogamous) relationship. This can be achieved by the producer application encrypting the message, and the consumer application decrypting the message. This will not impact your channels. Any producer not knowing the encryption key will send 'junk' messages to the queue; and the consumer can discard the message.
As pointed out in other posts here, any single or combination of unsecured channels (no MCAUSER specified) results in an unsecured qmgr. Think of this as installing locks with deadbolts on all but one of the doors/windows at your house.
| Quote: |
| (We can assume the machine on which the sender app runs is secure ... "not our problem"!) |
Since WMQ demo software is downloadable for free, some hacker (your end or the sender end) could attach to one of your channels, and put a message to one of your queues.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 04, 2010 8:03 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| mqdogsbody wrote: |
| mqjeff wrote: |
| As long as you have any channel, of any kind, coming into this queue manager that does not have any MCAUSER set, then the possibility exists that your queue is not secure. |
But (sans exit) can't anybody connect via any channel, thus gaining use of the special user ID used for the sensitive queue? |
Yes, that's why your special channel with the special ID needs to be SSL or Exit protected to insure only the correct person can use it, meanwhile every other incoming channel needs to be tagged with IDs that do not have access to the special queue. Whether you authenticate those other channels with an exit or SSL is not relevent to the access allowed to the special queue.
You can of course write a custom super duper API exit that intercepts every MQ APi call and does its own blocking and checking and etc, and invalidates what I said is required, but I think we'll agree that's overkill.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 04, 2010 8:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqdogsbody wrote: |
| mqjeff wrote: |
| As long as you have any channel, of any kind, coming into this queue manager that does not have any MCAUSER set, then the possibility exists that your queue is not secure. |
But (sans exit) can't anybody connect via any channel, thus gaining use of the special user ID used for the sensitive queue? |
Anyone can connect to any channel that is not secured by SSL.
Enabling SSLCAUTH(REQUIRED) on a specific channel means that only people who have certificates that are trusted by the qmgr can connect to that channel.
Enabling SSLCAUTH and SSLPEER on a specific channel means that only people that have trusted certificates with DNs that match the SSLPEER value can connect to that channel. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 04, 2010 8:07 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| mqjeff wrote: |
Anyone can connect to any channel that is not secured by SSL.
|
A Security Exit also can prevent unauthenticated entities from connecting.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Fri Jun 04, 2010 8:08 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| bruce2359 wrote: |
| Yes, you are correct that MQ security documentation is scattered. |
You can delete "security" from that!
| bruce2359 wrote: |
| The producer of the message and the consumer of the message need to have a unique (monogamous) relationship. |
But, as I said, we cannot change the apps. My idea is that by using send/rcv exits and tagging the messages using a key (stored on the "secure" put- and get-client machines) we can achieve the same effect in a way transparent to the apps.
But there seems to be no documentation of these exits.
| bruce2359 wrote: |
| any single [...] unsecured channel (no MCAUSER specified) results in an unsecured qmgr. |
Great isn't it!
_________________
-- mqDB -- |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 04, 2010 8:09 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PeterPotkay wrote: |
| mqjeff wrote: |
Anyone can connect to any channel that is not secured by SSL.
|
A Security Exit also can prevent unauthenticated entities from connecting. |
Yes. |
|
| Back to top |
|
|
|
|
