| Author |
Message
|
| HenriqueS |
 Posted: Thu Jan 14, 2010 11:22 am Post subject: Your experience: SSL vs. BlockIP2 for SVRCONN channels. |
 |
|
Master
Joined: 22 Sep 2006
Posts: 235
|
Hello folks,
After some time having our SVRCONNs protected with SSL I am considering using BlockIP2 because of the administrative effort mantaining certificates, transporting them to every server and workstation (who uses MQ Explorer), etc.
What´s your opinion?
Regards, |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Fri Jan 15, 2010 3:32 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
IMHO blockip is an addition to ssl, not an replacement.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Volvic |
| Posted: Fri Jan 15, 2010 7:52 am Post subject: Re: Your experience: SSL vs. BlockIP2 for SVRCONN channels. |
|
|
Apprentice
Joined: 14 Oct 2009
Posts: 30
|
| HenriqueS wrote: |
Hello folks,
After some time having our SVRCONNs protected with SSL I am considering using BlockIP2 because of the administrative effort mantaining certificates, transporting them to every server and workstation (who uses MQ Explorer), etc.
What´s your opinion?
Regards, |
If you don't need message encryption and only want to block access then use BlockIP. If your connection goes though Internet then keep SSL.
_________________
Volvic |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 15, 2010 8:00 am Post subject: Re: Your experience: SSL vs. BlockIP2 for SVRCONN channels. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Volvic wrote: |
| If you don't need message encryption and only want to block access then use BlockIP. If your connection goes though Internet then keep SSL. |
You might also want to authenticate who's using one of the non-blocked addressed. This requires SSL.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jan 15, 2010 8:12 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| If you don't need message encryption and only want to block access then use BlockIP. If your connection goes though Internet then keep SSL. |
If you need encryption, but don't want SSL/TLS CA digital certificates, Capitalware has a few products that I've recommended to clients. http://www.capitalware.biz/
_________________
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 |
|
|
| HenriqueS |
| Posted: Fri Jan 15, 2010 8:20 am Post subject: Re: Your experience: SSL vs. BlockIP2 for SVRCONN channels. |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
1) The DQM channels are all encrypted in the application layer. So outgoing/incoming communication with business partners is 'secure'. RCVR channels will receive garbage data but the triggered application will reject it since it will fail the deciphering process.
*question: may a business partners stablish comm to my RCVR channels and perform something in the administrative field...like sending PCF messages..just by creating a remote queue definition to SYSTEM.DEFAULT.COMMAND.QUEUE?
2) The SVRCONN channels used for administration and monitoring purposes are the ones I am referring to. So yes, it´s all internal (LAN).
3) Roughly we have less than 10 servers and workstations with their respective users that do interact with these SVRCONN channels running MQExplorer or 'MQMon' (in house monitoring/alert app I developed).
4) People usually do not switch workstations here except when a new one comes in (every 2/3 years). Same for servers.
What do you guys think? |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 15, 2010 8:26 am Post subject: Re: Your experience: SSL vs. BlockIP2 for SVRCONN channels. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| HenriqueS wrote: |
| *question: may a business partners stablish comm to my RCVR channels and perform something in the administrative field...like sending PCF messages..just by creating a remote queue definition to SYSTEM.DEFAULT.COMMAND.QUEUE? |
I think you'll find that's SYSTEM.ADMIN.COMMAND.QUEUE and yes, if you've not properly secured your queue manager that's all you need to do to maliciously control a queue manager. Same is true (broadly) for connecting an instance of MQExplorer.
| HenriqueS wrote: |
| 2) The SVRCONN channels used for administration and monitoring purposes are the ones I am referring to. So yes, it´s all internal (LAN). |
What a channel is supposed to be used for & what it can be used for is what security is for. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jan 15, 2010 8:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Unless you take steps to ensure that all incoming channels are mapped into correct security roles, then merely blocking the incoming channels from "bad" network locations does nothing.
One advantage that BlockIP may have over SSL is that it may be able to map incoming users on a single channel onto different security roles. SSL+MCAUSER can only map all incoming users on a single channel into a single security role.
One disadvantage of this in general is that you are still relying on the ID that is presented by the other end of the incoming channel. Just as nothing prevents an unscrupulous, overzealous or sloppy business partner from sending PCF messages to your Command Server Queue, nothing prevents them from creating a user on their system that has any name it wants.
SSL avoids this by using the properties of the *certificate*, which has been digitally signed, to determine whether the remote end is who it says it is. |
|
| Back to top |
|
|
| HenriqueS |
| Posted: Fri Jan 15, 2010 8:48 am Post subject: Re: Your experience: SSL vs. BlockIP2 for SVRCONN channels. |
|
|
Master
Joined: 22 Sep 2006
Posts: 235
|
| Quote: |
[quote="Vitor"]
| HenriqueS wrote: |
| *question: may a business partners stablish comm to my RCVR channels and perform something in the administrative field...like sending PCF messages..just by creating a remote queue definition to SYSTEM.DEFAULT.COMMAND.QUEUE? |
I think you'll find that's SYSTEM.ADMIN.COMMAND.QUEUE and yes, if you've not properly secured your queue manager that's all you need to do to maliciously control a queue manager. Same is true (broadly) for connecting an instance of MQExplorer.
|
I just realized that we have an exit here running that catches this condition - when we receive a message from a business partner targeting something else that it is supposed to. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 15, 2010 8:56 am Post subject: Re: Your experience: SSL vs. BlockIP2 for SVRCONN channels. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| HenriqueS wrote: |
| I just realized that we have an exit here running that catches this condition - when we receive a message from a business partner targeting something else that it is supposed to. |
Just assume I've given my usual comments & warnings about exits here ok?
But I'd take that as at least part of "properly securing the queue manager", yes.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 15, 2010 12:22 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
SSL avoids this by using the properties of the *certificate*, which has been digitally signed, to determine whether the remote end is who it says it is. |
I wouldn't say it avoids it. If I give you an SSL cert and access to my QM, I will know its mqjeff, but there is nothing preventing you from deleting all my queues, unless I tag the MCAUSER with an ID that does not have that ability.
If you do not have your channels running under an ID* that is specifically limited to what queues they can access, you are basically allowing full administrative control to the incoming connection. SSL or an Exit only means you'll know if its a particular person, assuming the SSL certs are secure and didn't grow legs. Not having SSL or an Exit means anyone can do anything if the channel's ID is not limited.
*You could have a fancy Security Exit that looks at each MQ API call and determines if it shoudl allow the call, but that seems overkill to me compared to securing the channel with a proper ID.
IF you use a free exit, and IF it contains a bug (I'm not saying BlockIP does) and you have a problem, whose accountable? Have fun explaining to your bosses that the security breach was caused by freeware. With a commercially purchased exit, you can pass the buck to the vendor. Repeat: I am not saying BlockIP has or has not any bug.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Jan 15, 2010 12:33 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| PeterPotkay wrote: |
If I give you an SSL cert and access to my QM, I will know its mqjeff, but there is nothing preventing you from deleting all my queues, unless I tag the MCAUSER with an ID that does not have that ability.
|
there is no forced relation between SSL cert and userid for example in MCAUSER.
Even if you force SSL only for authentication and set MCAUSER, you still need to set SSLPEER to limit the access to the one the access is intended for, otherwise you let anyone in with a signed certificate that matches the for example the CA certs in the keystore...
the more I get involved in security matters and the more I think about it,
the more I see how insecure (default) MQ really is, unless you take a lot of precautions... sometimes it's mind boggling...
and it all started with a bunch of *sshol* java programmers that could not deal with 2035 errors...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 15, 2010 12:54 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I agree Michael. When I enable SSL, I consider it pointless without correct SSLPEER values. I should have been more explicit.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
