| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Quality of message protection |
« View previous topic :: View next topic » |
| Author |
Message
|
| lanny boy |
 Posted: Mon Oct 17, 2005 7:28 am Post subject: Quality of message protection |
 |
|
Voyager
Joined: 24 Nov 2003
Posts: 79
Location: UK
|
I have been looking at the security/integrity of messages being processed by the broker.
The documentation states that...
| Quote: |
| The authentication services provided by WebSphere Business Integration Message Broker ensure that only legitimate event broker servers and clients can connect to each other. However, a hacker might still be able to observe messages in transit or tamper with messages on established connections |
Obviously this implies that there is a risk of tampering as with any other electronic transfer of data.
Has anybody any experience of this knd of threat?
There doesn't seem to be much that can be done about this or am i wrong? Maybe the enableQopSecurity parameter of mqsicchangeproperties cmd?
Does this apply to only pub/sub functionality or useful in securing the integrity of data?
Any feedback would be great. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Oct 17, 2005 7:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you wish to secure MQ messages in transit, you should enable SSL on all of your MQ channels, particularly client channels.
It gets a little bit harder to secure HTTP messages to/from broker using SSl, but you can probably use something like STunnel to do this (or migrate to v6 and set the HTTPInput nodes to use SSL).
I don't know about securing MQRealTime. I think this is covered, thoguh.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| lanny boy |
| Posted: Mon Oct 17, 2005 7:47 am Post subject: |
|
|
Voyager
Joined: 24 Nov 2003
Posts: 79
Location: UK
|
Hi Jeff,
Thanks for your reply.
It's not so much messages in transit between QM's i am concerned about, as SSL would solve this problem.
However is it possible to tamper with messages being moved from local Queue A to Queue B on the same QM, by the broker???
IF this is a risk are there any security steps which could be taken to minimise this. I personally don't the feel the risk is very real but I need to reassure other people as well!! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 17, 2005 7:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Messages don't move from qlocal to qlocal except by way of an application.
The only way to tamper with messages on a queue is to get them, edit them, and put them back. (or spend an incredible amount of time learning how to edit the queue data files, and then find out how to hack the qmgr server to get access to those files). Most organizations make it difficult to load applications onto servers, so it's usually very difficult to sneak apps that use bindings connections onto a machine.
SSL is not just for securing transport between two queue managers. It's an excellent way to secure your QM itself. If all channels have SSL on them, particularly svrconns, then only machines that have the right certs can access the qm. This will also prevent rogue client apps from getting to messages on a queue.
If you really need to do something more, you can use an API crossing exit or some such to encrypt and decrypt messages on the fly. But this is expensive, complicated and still subject to some vulnerability.
But remember that the security of a system is equal to the least secure piece.
Likely, the QOP of your messages is not the largest vulnerability you need to worry about.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kingsley |
| Posted: Mon Oct 17, 2005 9:04 am Post subject: |
|
|
Disciple
Joined: 30 Sep 2001
Posts: 175
Location: Hursley
|
I would suggest you to encrypt the message at the application level before placing it on the Queue.
That ensures even the hacker can't hack.
The downside of it is, if you are sending the messages across Operating systems, then the same decryption tool should be used and conversion has to be done when the message crosses the platform. The scenario is too dangerous for messages reaching and moving out of Z/OS. |
|
| Back to top |
|
|
| hopsala |
| Posted: Mon Oct 17, 2005 10:17 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| kingsley wrote: |
| I would suggest you to encrypt the message at the application level before placing it on the Queue. |
I personally do not favour this solution, but would rather harden security settings using setmqaut and SSL-configured channels; if you've done this properly, you've already ensured that "even the hacker can't hack" your data or setup. And concerning using both approaches together, contrary to common opinion, I do not believe that doubling your security layers is worth it, except maybe in truely problematic environments (i.e the army and such); it is usually more work then it's worth, aside from adding complexity to the system, since admistration becomes much more cumbersome (deadq handlers have to use decryption etc).
There is also a strange but somewhat common phenomenon i've seen in a number of sites i've consulted - when investing time encrypting the messages, less time is spent hardening local security, and thus systems remain wide-open access-wise with encrypted messages. This situation is worse than the opposite (normal msgs, no access) since the hacker can quickly log in, take a bunch of messages, and scurry out, decrypting msgs at his leisure; while in the opposite scenario he has to remain connected for the duration of the hack, which is far riskier and prone to detection. |
|
| 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
|
|
|
|
