| Author |
Message
|
| RogerLacroix |
 Posted: Mon Jun 07, 2010 8:15 am Post subject: Re: Unspoofable messages. |
 |
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
| 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. |
In the design of MQ, IBM divided security into 2 parts authentication (which the queue manger does NOT do) and authorization.
Authorization is handle by OAM. i.e. You use setmqaut to set the user's (or better group's) permissions to a MQ objects (i.e. queues).
You are looking at MQ security as one topic but it is 2 topics. Therefore, no matter if you implement SSL or a security solution (security exits) you still need to deal with BOTH authentication and authorization.
| mqdogsbody wrote: |
| We cannot lock down all channels at this stage - the risk of disruption is too great! |
Well then, there is really no point in doing anything. There is no point in locking one window in your house and leaving all the other windows and doors unlocked (actually wide open). A hacker (thief) will not try to break the locked channel (door), they will simply use the unlocked channel (door).
| mqdogsbody wrote: |
| 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 |
As I have said many, many times, setting MCAUSER field of a channel is NOT security. All it means is that anybody and everybody connecting to a queue manager on this particular channel will get the same permission to the MQ objects (queues). If the UserID set in the MCAUSER field does not have required permission to a particular queue then a hacker will simply try another channel.
Just because you say to someone, you are to only use channel "XYZ" does not mean they have to use it. If channel "ABC" has 'mqm' or another UserID set in the MCAUSER field with the appropriate permission then the hacker will use it.
One of my top 'open source' downloads is MQ Port Scan. It is for MQAdmins to test if their MQ environments is secure but the inverse is also true. 
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Mon Jun 07, 2010 8:30 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
| mqjeff wrote: |
| 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. |
mqDB, just in case you do not know Jeff is an IBM employee, who is NOT allowed to discuss solutions that are not IBM approved solutions. The only 2 IBM 'approved' MQ solutions that Jeff can recommend are SSL (builtin) and WebSphere MQ Extend Security Edition (WMQ ESE).
SSL is node-to-node security and not end-to-end security (no matter how someone tries to spin the topic).
There are 3 commercial end-to-end security solutions (security exits) for MQ:
1. Capitalware's MQ Authenticate User Security Exit (MQAUSX)
2. IBM's WebSphere MQ Extended Security Edition
3. Primeur's Data Secure for WebSphere MQ
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jun 07, 2010 8:52 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
From the OP:
| 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. (We can assume the machine on which the sender app runs is secure ... "not our problem"!) |
As you have discovered from this post, WMQ does not offer an application-through-channel-to-queue security solution - especially without changing anything.
WMQ offers channel-end-to-channel-end security with SSL. This is effective for ensuring that known channel-ends (with certs) attach, and others cannot attach. There is no implicit or explicit relationship between channels and queues. Channels are merely pipes through which messages flow.
WMQ offers username authorization checking at some of the MQI calls. This is how the channel-end MCA works to ensure that the MCA has (or does not have) sufficient authority to MQOPEN a destination queue.
Again, there is no explicit/implicit relationship between an MCA and a queue. The MCA uses its own authority (MCAUSER, if set), or it can use the authority of the userid found in the context fields of the message descriptor header (MQMD built by the requesting application).
I have recommended Rogers MQAUSX to clients that didn't/couldn't make application-level changes. But the issue of one channel being (semi-)secured while other channels remain unsecured is still a ecurity exposure.
_________________
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 |
|
|
| mqdogsbody |
| Posted: Tue Jun 08, 2010 2:47 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| bruce2359 wrote: |
| As you have discovered from this post, WMQ does not offer an application-through-channel-to-queue security solution |
Yes, but I had rather guessed that already. Everything one finds by Googling basically says "you can't".
I was vaguely hoping for something a bit more positive... |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Tue Jun 08, 2010 3:11 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| RogerLacroix wrote: |
| mqDB, just in case you do not know Jeff is an IBM employee, who is NOT allowed to discuss solutions that are not IBM approved solutions. |
I had rather guessed that from some of his other contributions to these forums. It is good of him to help out.
In which case, I have this question:
| The IBM MQ security manual wrote: |
| Send and receive exits can be used on both message and MQI channels. .... Send and receive exits have access to each transmission segment. They can modify its contents and change its length |
This is exactly what I want to do! But how can I do it if I am allowed to know nothing about the transmission segment except for the meaning of one byte?
| The IBM MQ security manual wrote: |
| Send and receive exits can be used to encrypt and decrypt the data that flows on a channel ... they can be used to compress and decompress the data that flows on a channel |
I guess in these cases you are supposed to encrypt/compress the whole TSH in your send exit and reverse the operation in your receive exit so you don't need to know the structure of the TSs.
And another question: There is a section in the "The IBM MQ intercommunication manual" called "How you reserve space and use it". But it doesn't seem to tell me how I actually use it.
| The IBM MQ intercommunication manual wrote: |
| ExitSpace bytes are reserved in the transmission buffer. |
I assume they are at the end (as defined by *pLDataLength). Is that correct?
| RogerLacroix wrote: |
| SSL is node-to-node security and not end-to-end security (no matter how someone tries to spin the topic). |
...and that's my problem ... as people keep on pointing out!
| RogerLacroix wrote: |
| There are 3 commercial end-to-end security solutions (security exits) for MQ |
I have tried to persuade my boss to look at these (more than once). Not much joy! If it is as important as he says it is, the company shouldn't be balking at spending money.
_________________
-- mqDB -- |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 08, 2010 3:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| RogerLacroix wrote: |
| mqDB, just in case you do not know Jeff is an IBM employee, |
This is true.
| RogerLacroix wrote: |
| who is NOT allowed to discuss solutions that are not IBM approved solutions. |
This is not true.
I repeat. This statement by Roger is NOT true. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 08, 2010 5:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I was vaguely hoping for something a bit more positive... |
In this same category, I'd like my 1994 Honda Civic to perform like the car it replaced, namely: a Porsche.
Hope is positive, but then reality sets in.
Reality check.
_________________
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 |
|
|
| fjb_saper |
| Posted: Tue Jun 08, 2010 10:34 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
If you really want spoof proof content you need something like the following:
a multipart content or a content over multiple messages (group).
- First part is the actual content
- Second part is the digital signature of the content.
Now if the sender and receiver have exchanged their keys the receiver can verify the signature on hand and thus verify that the message has
- originated from the sender
- not been tempered with
However this is not done automagically and if you need this kind of functionality you'd have to code for it.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 08, 2010 11:01 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
...which means an application-level solution.
_________________
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 |
|
|
| RogerLacroix |
| Posted: Tue Jun 08, 2010 3:06 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
Hi,
| mqdogsbody wrote: |
| RogerLacroix wrote: |
| There are 3 commercial end-to-end security solutions (security exits) for MQ |
I have tried to persuade my boss to look at these (more than once). Not much joy! If it is as important as he says it is, the company shouldn't be balking at spending money. |
You need to separate Authentication (i.e. MQAUSX) from message encryption and decryption. MQ security exits are ONLY invoked for MQCONN/X and MQDISC MQ API calls. MQ security exits never "see" the data.
And yes, I have a product that handles message encryption and decryption: MQ Channel Encryption
| mqdogsbody wrote: |
| The IBM MQ security manual wrote: |
| Send and receive exits can be used on both message and MQI channels. .... Send and receive exits have access to each transmission segment. They can modify its contents and change its length |
This is exactly what I want to do! But how can I do it if I am allowed to know nothing about the transmission segment except for the meaning of one byte? |
Exactly. IBM does not publish the specs for TSH structure.  It takes a WHOLE LOT of trial and error. Been there, done that.
| mqdogsbody wrote: |
| The IBM MQ security manual wrote: |
| Send and receive exits can be used to encrypt and decrypt the data that flows on a channel ... they can be used to compress and decompress the data that flows on a channel |
I guess in these cases you are supposed to encrypt/compress the whole TSH in your send exit and reverse the operation in your receive exit so you don't need to know the structure of the TSs. |
This is a very dangerous approach.
| mqdogsbody wrote: |
There is a section in the "The IBM MQ intercommunication manual" called "How you reserve space and use it". But it doesn't seem to tell me how I actually use it.
| The IBM MQ intercommunication manual wrote: |
| ExitSpace bytes are reserved in the transmission buffer. |
I assume they are at the end (as defined by *pLDataLength). Is that correct? |
pDataLength is the length of the data in the buffer (not the length of the buffer). You can put whatever you want in the buffer (start, middle or end).
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 08, 2010 4:35 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
As has been mentioned here, securing only one channel leaves all other channels unsecured - which means that a message could arrive on a unsecured channel, AND end up in the application queue you are concerned about. It is the XQH (transmission queue header) built by the sending qmgr that determines which queue the message goes to.
_________________
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 |
|
|
| mqdogsbody |
| Posted: Wed Jun 09, 2010 9:00 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
So many points to respond to. To keep things simple I'll do it point-by-point starting with...
| RogerLacroix wrote: |
| mqdogsbody wrote: |
| The IBM MQ security manual wrote: |
| Send and receive exits can be used on both message and MQI channels. .... Send and receive exits have access to each transmission segment. They can modify its contents and change its length |
This is exactly what I want to do! But how can I do it if I am allowed to know nothing about the transmission segment except for the meaning of one byte? |
Exactly. IBM does not publish the specs for TSH structure. |
Then how do IBM expect you do do the things they promise you can do? They seem to be saying "You can do wonderful things ... but we aren't going to tell you how -- and we disapprove of any way you might come up with of doing these things too!"
One for mqjeff I suppose!
| RogerLacroix wrote: |
| :( It takes a WHOLE LOT of trial and error. Been there, done that. |
Well, I seem to have managed OK: can get a checksum added by the channel exit to messages as they are put and strip it off on get. But of course, my solution is "fragile".
| RogerLacroix wrote: |
| mqdogsbody wrote: |
| The IBM MQ security manual wrote: |
| Send and receive exits can be used to encrypt and decrypt the data that flows on a channel ... they can be used to compress and decompress the data that flows on a channel |
I guess in these cases you are supposed to encrypt/compress the whole TSH in your send exit and reverse the operation in your receive exit so you don't need to know the structure of the TSs. |
This is a very dangerous approach. |
I wasn't planning to do it; just speculating on how IBM might justify saying you can encrypt/decrypt the data when they don't tell you where it is. I was thinking that if the send exit encrypts the whole TSH and the receive exit decrypts it MQ might be none the wiser.
| RogerLacroix wrote: |
| mqdogsbody wrote: |
| I assume they are at the end (as defined by *pLDataLength). Is that correct? |
pDataLength is the length of the data in the buffer |
Yes: when I said "at the end" I meant the end of the data, not the end of the buffer.
| RogerLacroix wrote: |
| You can put whatever you want in the buffer (start, middle or end). |
Fair enough: I was imagining thimgs might be more sophisticated than they are. Is it fair to say that the whole buffer from the start of the message to the buffer-end is mine to play with, as long as I update the lengths recorded in various (undocumented) places? What's the role of ExitSpace then?
| RogerLacroix wrote: |
Regards,
Roger Lacroix
Capitalware Inc. |
Thanks for your help!
_________________
-- mqDB -- |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Jun 09, 2010 2:24 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
| mqdogsbody wrote: |
| Then how do IBM expect you do do the things they promise you can do? They seem to be saying "You can do wonderful things ... but we aren't going to tell you how -- and we disapprove of any way you might come up with of doing these things too!" |
I really do not know the answer other than IBM does not want you playing with the TSH.
| mqdogsbody wrote: |
| Well, I seem to have managed OK: can get a checksum added by the channel exit to messages as they are put and strip it off on get. But of course, my solution is "fragile". |
Checksum is not encryption plus the MCA is already doing checksum processing as the message crosses the wire.
| mqdogsbody wrote: |
| Is it fair to say that the whole buffer from the start of the message to the buffer-end is mine to play with, as long as I update the lengths recorded in various (undocumented) places? |
True.
| mqdogsbody wrote: |
| What's the role of ExitSpace then? |
It is documented in the WMQ Intercommunication manual.
Please remember, exits are an advanced-level topic. Make sure you are thinking in terms of parallel processing. Also, watch out for ASCII <--> EBCDIC and Big-Endian <--> Little-Endian issues.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Thu Jun 10, 2010 3:40 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| RogerLacroix wrote: |
| mqdogsbody wrote: |
| What's the role of ExitSpace then? |
It is documented in the WMQ Intercommunication manual. |
Well, I just came across this sentence (on the "ExitSpace (MQLONG)" page): "The exit space in the buffer is provided following the existing data." Must have missed that before.
But (if the TSH is undocumented) how I am supposed to know where the existing data ends?
| RogerLacroix wrote: |
| Please remember, exits are an advanced-level topic. |
I am all to aware of this. My answer has been "Call in IBM" but I have been ignored.
_________________
-- mqDB -- |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 10, 2010 5:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqdogsbody wrote: |
| My answer has been "Call in IBM" but I have been ignored. |
Then escalate your issue through your IBM account rep. You pay good money for the license and are entitled to at least a response.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
